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ABSTRACT 


This  report  documents  the  first  phase  of 
a  three  phase  effort  directed  towards  developing 
a  Navy  digital  data  exchange  strategy  for  CALS. 
The  data  exchange  strategy  task  has  been  divided 
into  three  distinct  parts.  Part  I  is  documented 
in  this  report  and  provides  an  overview  of  data 
exchange.  It  includes  a  discussion  of  data 
exchange  concepts,  a  summary  of  current  and 
potential  future  CALS  standards,  and  a  brief 
overview  of  selected  industry  approaches  to 
digital  data  exchange.  It  is  intended  to  provide 
the  reader  with  a  single  reference  source  to 
become  familiar  with  the  area  of  data  exchange/ 
data  exchange  standards  and  related  activities. 
This  document  will  serve  as  a  reference  document 
to  the  Navy's  Acquisition  Guide  for  Program 
Managers . 


ADMINISTRATIVE  INFORMATION 

The  work  presented  in  this  report  was  accomplished  at  the 
David  Taylor  Research  Center  under  OMN  funding  for  the  Integrated 
Logistics  Support  Plans,  Policy,  and  Assessment  Division  (OP-46) , 
Deputy  Chief  of  Naval  Operations  (Logistics) .  Sponsorship  of  the 
work  has  transitioned  to  the  Logistics  Policy  Branch  (OP-403) . 
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EXECUTIVE  SUMMARY 


CALS  is  a  DoD  and  Industry  initiative  to  enable  and  accelerate 
the  use  and  integration  of  digital  technical  information  for  weapon 
system  acquisition,  design,  manufacture,  and  support.  Through 
CALS,  a  transition  from  a  paper  intensive  mode  of  operation  to  an 
automated  and  integrated  mode  is  in  progress.  This  is  aimed  at 
improving  both  the  productivity  and  quality  of  the  weapons  system 
acquisition  and  logistics  support  process. 

While  DoD  is  developing  the  corporate  plans  and  architecture 
to  establish  the  overall  direction  of  the  CALS  implementation 
strategy,  each  service  is  responsible  for  its  own  implementation. 
The  purpose  of  this  report  is  to  provide  support  to  OPNAV  in  the 
development  of  a  Navy  strategy  for  digital  data  exchange  in  support 
of  the  CALS  initiative.  This  report  documents  the  first  phase  of 
a  three  phase  effort  directed  towards  developing  a  Navy  digital 
data  exchange  strategy  for  CALS.  The  data  exchange  strategy  will 
be  instrumental  in  the  Navy  approach  to  implementing  CALS. 

The  data  exchange  strategy  task  has  been  divided  into  three 
distinct  parts.  Part  I  is  documented  in  this  report  and  provides 
an  overview  of  data  exchange.  It  includes  a  discussion  of  data 
excnange  concepts,  a  summary  of  current  and  potential  future  CALS 
standards,  and  a  brief  overview  of  selected  industry  approaches  to 
digital  data  exchange.  It  is  intended  to  provide  the  reader  with 
a  single  reference  source  to  become  familiar  with  the  area  of  data 
exchange/data  exchange  standards  and  related  activities.  This 
document  will  serve  as  a  reference  document  to  the  Navy's 
Acquisition  Guide  for  Program  Managers. 

To  provide  a  baseline  for  discussion  in  data  exchange,  this 
report  introduces  a  number  of  data  exchange  concepts.  The  concepts 
presented  include  translators  (direct,  neutral,  and  flavoring) , 
application  subsets  and  protocols,  and  testing  (loop,  end-to-end, 
verification,  and  application  validation) . 

Many  organizations  are  presently  creating  and  maintaining 
their  data  using  electronic  systems  because  of  the  gains  in 
productivity  and  cost  savings.  These  computer  based  systems  have 
broad  applications  in  CAD/ CAM  (Computer  Aided  Design/ Computer  Aided 
Manufacturing) ,  and  Electronic  Publishing.  A  variety  of  different 
vendors  developed  these  generic  software  systems  and  store  the  data 
created  on  their  proprietary  software  systems  in  their  own 
proprietary  formats.  The  stored  data  represents  computer  based 
models,  design,  drawings,  technical  documentation,  and 
manufacturing  information.  While  the  vendors  proprietary  format 
is  designed  for  efficiency,  files  stored  in  the  vendors  own  non¬ 
standard  format  cannot  be  read  by  or  electronically  transferred  to 
another  software  system. 


Standards  and  specifications  are  being  developed  by  CALS  to 
provide  the  common  interfaces  needed  to  improve  Industry  and  DoD 
productivity  and  quality  in  both  acquisition  and  logistic  support 
in  the  interchange  and  efficient  use  of  digital  data.  CALS  phase 
I  focuses  on  standards  for  digital  interchange  of  technical 
information  among  dissimilar  computer  systems.  Initial  CALS 
standards  are  intended  to  enable  the  digital  delivery  of 
engineering  drawings  and  technical  manuals  including  illustrations. 
CALS  phase  II  focuses  on  the  standards  needed  to  access  and  manage 
data  within  a  distributed  data  base.  MIL-HDBK-59 ,  Computer  Aided 
Acquisition  and  Logistic  Support  (CALS)  Program  Implementation 
Guide,  is  DoD's  guidance  document  for  the  implementation  of  CALS. 
Each  service  is  responsible  for  issuing  implementation  guidance  of 
their  own.  MIL-HDBK-59  provides  an  overview  of  CALS  and  provides 
guidance  on  the  use  and  delivery  of  digital  data.  Under  that 
standard  lies  MIL-STD-1840A,  Automated  Interchange  of  Technical 
Information,  which  provides  technical  information  on  the 
specifications  used  in  CALS,  the  packaging  of  the  digital  form,  and 
basic  concepts. 

Current  CALS  data  exchange  standards/specifications  are: 

1.  MIL-STD-1840A,  "Automated  Interchange  of  Technical 
Information" 

2.  MIL-D-28000,  "Digital  Representation  for  Communication 
of  Product  Data:  IGES  Application  Subsets" 

3.  MIL-M-28001,  "Markup  Requirements  and  Generic  Style 
Specification  for  Electronic  Printed  Output  and 
Exchange  of  Text" 

4.  MIL-R-28002,  "Requirements  for  Raster  Graphics 
Representation  in  Binary  Format" 

5.  MIL-D-28003,  "Digital  Representation  for  Communication 
of  Illustration  Data:  CGM  Application  Profile" 

Future  standards  will  address  data  interchange  in  terms  of 
both  technical  data  elements  and  the  life  cycle  functional 
applications  that  use  the  technical  data.  Future  CALS  data 
exchange  standards  are  likely  to  include: 

6.  MIL-STD-1388-2B, "  Logistic  Support  Analysis  Record" 

7.  PDES ,  Product  Data  Exchange  Specification 

8.  EDIF,  Electronic  Data  Interchange  Format 

9.  VHDL,  VHSIC  Hardware  Description  Language 

10.  ODA,  Office  Document  Architecture 
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A  brief  overview  of  selected  industry  approaches  to  digital 
data  exchange  is  presented  and  is  not  intended  to  represent  a 
complete  description  of  any  company's  activities  but  rather  to 
provide  an  insight  into  each  company's  recognition  of  the 
importance  of  digital  data  exchange  and  their  approach  to 
addressing  the  problem.  The  companies  highlighted  are  McAir, 
Newport  News  Shipbuilding,  Northrop  Aircraft  Division,  and 
Westinghouse  Electronic  Systems  Group. 

Part  II  of  this  task  will  provide  a  summary  and  evaluation  of 
current  CALS-related  on-going  Navy  data  exchange  activities,  and 
Part  III  will  develop  an  approach  to  the  strategy  for  Navy  digital 
data  exchange. 
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1.0  DATA  EXCHANGE  OVERVIEW 

1 . 1  INTRODUCTION 

DoD  and  Industry  are  embarking  on  the  Computer  Aided 
Acquisition  and  Logistics  Support  (CALS)  initiative  to  accelerate 
the  use  and  integration  of  digital  technical  information  for  weapon 
system  acquisition,  design,  manufacture,  and  support.  Through 
CALS,  a  transition  from  a  paper-intensive  mode  of  operation  to  an 
automated  and  integrated  mode  is  in  progress.  This  is  aimed  at 
improving  both  the  productivity  and  the  quality  of  the  weapons 
system  acquisition  and  logistics  support  process. 

Many  organizations  are  presently  creating  and  maintaining 
their  data  using  electronic  systems  because  of  the  gains  in 
productivity  and  cost  savings.  These  computer  based  systems  have 
broad  applications  in  CAD/ CAM  (Computer  Aided  Design/Computer  Aided 
Manufacturing) ,  and  Electronic  Publishing.  A  variety  of  different 
vendors  developed  these  generic  software  systems  and  store  the  data 
created  on  their  proprietary  software  systems  in  their  own 
proprietary  formats.  The  stored  data  represents  computer  based 
models,  design,  drawings,  technical  documentation,  and 
manufacturing  information.  While  the  vendors  proprietary  format 
is  designed  for  efficiency,  files  stored  in  the  vendors  own  non¬ 
standard  format  cannot  be  read  by  or  electronically  transferred  to 
another  software  system. 

In  many  cases  the  use  of  vendor  proprietary  formats  poses  no 
problem  to  the  user.  As  long  as  all  organizations  requiring  the 
data  are  using  the  same  software,  accessing  the  data  can  be 
achieved  effortlessly.  But  other  departments  within  the  company 
or  other  companies  having  dissimilar  hardware/software  may  have  a 
need  to  access  the  data.  For  example,  a  design  engineer  may  create 
a  part  model  which  could  be  used  by  the  reliability  and 
maintainability  engineers,  by  logistics  support  and  analysis,  by 
manufacturing  and  by  technical  publications  for  their  own  work. 
If  these  other  departments  use  a  non-homogeneous  software  system 
(different  from  the  one  on  which  the  data  was  originally  created)  , 
the  data  can  either  be  re-entered  manually  or  exchanged 
electronically  using  translators.  A  drawback  to  entering  data 
manually  is  the  introduction  of  errors  as  the  data  is  re-entered, 
and  the  duplication  of  effort.  When  the  transfer  is  infrequent  and 
small  (and  the  people  re-entering  the  data  are  inexpensive) ,  this 
can  be  a  viable  option.  If  the  frequency  and  volume  of  data 
exchanged  make  this  method  prohibitively  expensive,  a  decision  is 
often  made  to  transfer  the  data  electronically. 


1.2  DIRECT  TRANSLATORS  VS.  NEUTRAL  FILE  TRANSLATORS 

Once  an  organization  has  decided  to  exchange  data 
electronically,  a  further  choice  must  be  made  as  to  whether  a 
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direct  translator  or  a  neutral  file  translator  will  be  used.  Both 
methods  have  advantages  and  disadvantages. 


A  direct  translator  allows  the  user  to  pass  information 
directly  from  one  software  system  to  another,  without  an  interim 
stop  at  a  neutral  file.  This  approach  can  be  tightly  coupled  to 
the  application  being  dealt  with,  because  only  two  software  systems 
are  being  considered  and  the  exchange  does  not  need  to  be  kept 
general.  This  type  of  translator  is  usually  highly  efficient  and 
can  be  a  good  short  term  approach  to  data  exchange. 

Descriptions  of  digital  data  exchange  concepts  presented  in 
this  data  exchange  overview  section  have  general  applicability,  but 
are  described  in  terms  of  Computer  Aided  Design  (CAD)  and  the 
Initial  Graphics  Exchange  Specification  (IGES)  in  order  to  provide 
a  focus  for  illustrative  purposes. 

The  use  of  direct  translators  may  result  in  additional 
software  maintenance  efforts  as  when  the  vendor  releases  a  new 
version  of  the  CAD  system,  the  translation  software  will  need  to 
be  updated  because  the  translation  software  is  dependent  on  the  CAD 
software.  This  will  result  in  additional  costs  for  translation 
software  modification  and  testing.  Some  vendors  provide  a  software 
interface  to  access  their  databases,  insulating  the  direct 
translator  from  some  database  changes.  But  others  do  not,  which  may 
lead  to  problems  if  the  format  of  the  internal  database  changes, 
and  there  is  no  guarantee  that  the  format  of  the  internal  database 
will  remain  fixed.  CAD  systems  are  constantly  improving,  adding 
more  features  and  new  entities.  These  new  entities  must  be  added 
to  the  direct  translator.  Additional  problems  arise  if  translation 
is  required  between  more  than  two  systems.  With  the  direct 
translation  there  are  more  translators  to  support  than  with  neutral 
file  format  translation. 

The  exchange  is  a  one  step  process,  but  two  translators  are 
needed  for  every  software  system  involved  in  the  exchange.  One 
translator  to  send  data  to  the  other  receiving  software  system  and 
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another  to  get  data  back.  The  example  given  in  Figure  1  of  four 
different  software  systems  would  require  twelve  translators  to  be 
written;  two  translators  between  each  software  system  shown.  If 
there  are  five  systems,  the  number  of  translators  required  goes  up 
to  twenty.  For  n  systems,  n(n-l)  translators  would  be  required.  As 
vendors  modify  their  internal  software  and  data  bases,  the  result 
can  be  a  real  maintenance  nightmare. 


Figure  1.  Direct  Translators 


A  neutral  format  file  is  a  nonproprietary  format  available  for 
public  use,  generally  as  a  national  or  international  standard.  It 
is  a  common  medium  for  sharing  data  electronically  between 
different  software  systems.  It  is  an  appealing  concept  because  only 
two  pieces  of  translation  software  need  to  be  written  for  a 
software  system,  no  matter  how  many  software  systems  you  wish  to 
exchange  data  with  using  the  neutral  format  file.  These  pieces  of 
software  are  the  pre-processor,  which  reads  the  data  from  a 
software  system  into  the  neutral  format  file,  and  the  post¬ 
processor,  which  reads  the  neutral  format  file  into  the  software 
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system.  As  Figure  2  illustrates,  four  systems  wishing  to  exchange 
data  require  only  eight  pieces  of  software  to  be  written,  (two 
translators  to  support  each  system) ;  for  five  systems  the  number 
of  translators  required  goes  up  to  ten.  For  n  systems  wishing  to 
exchange  data  electronically,  only  2n  translators  need  to  be 
written.  Since  only  two  translators  are  required  for  each  system, 
the  software  vendor  usually  develops  the  translation  software, 
often  marketing  it  as  an  option  that  may  be  purchased  with  the 
system.  Vendor  supplied  and  supported  translators  shield  the  user 
from  updating  the  translation  software  when  a  new  version  of  the 
neutral  file  format  is  released. 
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Figure  2.  Neutral  File  Translators 


In  any  data  exchange  process,  there  are  a  multitude  of 
problems  which  may  occur  in  the  translation  process.  For  example, 
in  IGES  where  neutral  file  translators  are  used,  the  sending 
software  system  might  not  have  output  their  entire  CAD  model  into 
the  IGES  file.  All  the  functionality  on  one  software  system  may  not 
transfer  to  the  receiving  software  system,  i.e.  the  graphics  may 
transfer,  but  the  meaning  may  not.  The  neutral  file  specification 
may  be  ambiguous  in  places,  and  the  software  vendors  may  have 
interpreted  the  specification  differently  or  the  entity  may  simply 
have  been  transferred  incorrectly.  For  example,  in  transferring 
text,  a  particular  font  may  not  be  supported  by  IGES  and  the 
translator  may  have  been  developed  to  interpret  the  letters  as  line 
segments.  Although,  the  translation  will  result  in  a  perfect 
visual  match,  the  fact  that  the  line  segments  represent  text  (the 
meaning  or  functionality  of  the  line  segments)  will  be  lost. 

If  an  error  occurs  in  the  exchange,  the  software  system  that 
caused  the  error  must  be  identified  before  it  can  be  fixed.  First, 
the  user  must  determine  that  the  entity  was  sent.  A  translator  may 
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not  output  all  the  software  system's  native  entities  to  the  IGES 
file,  either  because  there  is  no  appropriate  IGES  entity  to 
translate  the  systems  native  entity  into  or  because  the  vendor 
hasn't  written  anything  yet  to  support  that  native  entity.  Then  the 
user  must  determine  if  the  receiving  system  can  read  that  type  of 
entity.  If  both  of  those  steps  were  satisfactory,  then  the  user 
must  determine  if  the  error  was  in  reading  or  writing  the  file. 
To  check  if  the  file's  structure  was  written  correctly,  an  IGES 
file  syntax  checker  may  be  used.  A  syntax  checker  confirms  that 
the  file's  structure  was  put  together  correctly.  If  the  IGES  file 
is  run  through  a  syntax  checker,  and  no  error  messages  are  produced 
for  the  entity,  it  would  indicate  that  the  error  is  probably  on  the 
receiving  software  systems  side. 

Often  there  will  be  a  choice  of  different  standards  to  use 
for  an  exchange.  Different  standards  usually  have  slightly 
different  design  intents  and  are  thus  better  in  some  applications 
than  in  others.  For  example,  one  could  transfer  a  picture  of  an 
engine  for  a  technical  repair  manual  using  IGES,  but  since  IGES 
was  intended  for  representing  engineering  drawings,  the  visual 
presentation  of  items  such  as  dimensions  or  text  fonts  may  not  be 
exact.  Another  standard  concerned  with  accurate  pictorial 
representations,  such  as  the  Computer  Graphics  Metafile  (CGM)  or 
Raster,  might  be  a  better  choice. 


1.3  STANDARDS,  SPECIFICATIONS  AND  THEIR  IMPLEMENTATIONS 

The  first  step  in  creating  a  national  standard  is  to  create 
a  specification,  which  can  be  thought  of  as  a  draft  standard.  The 
specification  documents  the  agreements  reached  by  consensus  of  a 
special  interest  group  which  addresses  the  problem  at  hand,  and 
contains  a  set  of  rules  for  defining  data  to  be  exchanged.  For 
example,  in  the  case  of  IGES  a  neutral  file  format  is  specified. 
This  special  interest  group  manages  the  development,  extensions  and 
documentation  of  the  potential  standard.  The  IGES/PDES  organization 
is  responsible  for  the  activity  for  the  IGES  specification.  Anyone 
interested  in  developing  the  standard  can  participate  in  the  group, 
and  after  attending  two  meetings  can  vote  on  issues  affecting  the 
standard. 

After  achieving  consensus  in  the  standards  making  body,  the 
standard  is  then  submitted  to  a  standards  endorsement  organization, 
such  as  the  Institute  of  Electrical  and  Electronics  Engineers 
(IEEE) ,  American  Society  of  Mechanical  Engineers  (ASME) ,  or  the 
Electronics  Industry  Association  (EIA) .  These  are  organizations 
that  have  been  sanctioned  by  the  American  National  Standards 
Institute  (ANSI)  to  approve  standards  as  ANSI  standards.  This 
provides  the  specification  a  broad  public  review.  The  specification 
is  then  published  and  released  as  a  standard,  after  a  successful 
review  and  balloting  process. 
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At  this  point  the  standard  is  not  usable  by  the  general  public 
as  it  is  simply  a  document  and  not  yet  implemented.  A  software 
developer  must  then  implement  the  standard  into  a  software  product 
before  it  can  be  used.  In  the  case  of  IGES,  the  software  product 
(called  a  translator)  transmits  only  the  set  of  entities  that  the 
software  developer  chose  to  implement.  In  actual  practice  the  set 
of  entities  implemented  by  the  vendor  is  a  subset  of  the  entities 
described  in  the  standard.  The  standard  does  specify  controls, 
formal  tests  or  certifications  to  check  that  the  implementation  was 
performed  correctly.  The  standard  also  may  lag  behind  the  current 
state  of  the  art  in  industry. 


1 . 4  TESTING 

1.4.1  LOOP  TESTING 

Loop  testing  and  end-to-end  testing  are  the  two  most 
common  types  of  testing  that  are  performed.  Loop  testing 
consists  of  sending  a  file  from  the  CAD  system  into  the  IGES 
format  and  then  reading  that  file  back  into  the  original  CAD 
system.  This  test  checks  whether  the  translator  can  read  in 
data  that  it  wrote.  It  is  a  basic  start  for  testing.  The 
problem  with  this  approach  is  that  the  same  person  or  group 
usually  writes  the  IGES  pre-processor  and  the  IGES  post¬ 
processor,  and  people  tend  to  be  consistent  when  they  misread 
the  specification.  So  loop  testing  tends  to  check  whether  the 
vendor  was  consistent  in  his  implementation  of  an  entity,  not 
whether  it  was  implemented  correctly. 


pre-processor 
- > 


post-processor 
< - 


IGES 

FILE 


Figure  3 .  Loop  Testing 


1.4.2  END-TO-END  TESTING 

End-to-End  testing  checks  the  transfer  of  data  from  one 
CAD  system  to  a  different  system.  If  the  data  does  not  appear 
as  expected  on  the  receiving  CAD  system,  the  IGES  file  must 
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be  examined  (see  IGES  File  Analysis,  section  1.4.3)  to  see  if 
the  data  was  put  there  correctly  by  the  sending  CAD  system. 
If  so,  then  the  errors  were  introduced  by  the  second 
translator  (post-processor) .  This  is  often  a  more  useful 
test,  as  it  tests  the  conditions  that  a  user  encounters  in  an 
actual  data  exchange.  The  CALS  Test  Network  was  established 
to  perform  end-to-end  testing  among  government  agencies  and 
between  government  and  industry. 


CAD 

CAD 

SYSTEM 

pre-processor 

IGES 

post-processor 

SYSTEM 

> 

> 

FILE 

A 
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Figure  4 .  End-t_o-End  Testing 


1.4.3  IGES  FILE  ANALYSIS 

There  are  many  IGES  products  on  the  market  that  aid  in 
the  process  of  testing.  IGES  file  analyzers  read  an  IGES  file 
and  check  its  syntax,  returning  an  analysis  of  the  syntax 
errors  (whether  the  file  format  is  correct)  and  warnings  about 
questionable  conditions.  Most  IGES  translators  also  check  the 
file  syntax,  but  not  to  the  extent  of  an  analyzer,  and  they 
will  not  return  all  the  diagnostic  messages  about  the  file 
that  an  analyzer  will.  One  point  to  keep  in  mind  when  using 
analyzers  is  that  they  are  software  systems  also,  so  they  may 
contain  errors. 


1.4.4  VERIFICATION  TESTING 

Verification  testing  is  performed  on  a  single  vendor's 
pre  and/or  post  translator.  It  tests  the  completeness  and 
correctness  of  the  entities  that  a  vendor  claims  to  have 
implemented  from  the  IGES  Specification  in  the  pre  and  post 
processor.  The  results  from  the  verification  test  should 
provide  information  for  users  to  make  their  own  evaluation  of 
the  value  of  a  particular  IGES  translator  for  their  particular 
application. 

The  IGES  Verification  Methodology  Committee  is  enhancing 
the  procedures  for  a  National  IGES  verification  program.  It 
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is  working  with  the  National  Institute  of  Standards  and 
Technology  (NIST)  and  the  Society  of  Automotive  Engineers 
(SAE)  to  set  up  an  initial  test  of  the  concept.  The  SAE  is 
functioning  as  the  independent,  impartial  party  needed  to 
conduct  and  direct  a  testing  effort,  and  NIST  is  providing  the 
initial  funding  needed  to  start  the  testing  effort.  It  is 
intended  to  be  self  funded  through  fees  charged  to  the  vendors 
after  the  initial  testing  of  the  methodology  is  finished. 
After  the  initial  test,  any  changes  needed  to  the  procedures 
will  be  made  and  the  formal  verification  testing  of  IGES 
translators  will  commence. 


1.4.5  APPLICATION  VALIDATION  TESTING 

Application  Validation  testing  attempts  to  confirm  that 
information  can  be  completely  and  reliably  exchanged  within 
a  given  application  area  (e.g.,  engineering  drawings,  3-D 
piping,  etc.).  It  is  concerned  with  determining  whether  the 
product  data,  all  the  information  needed  to  specify  and 
support  the  product  over  its  lifetime,  is  transferred  from  one 
CAD  system  to  another.  IGES  translators  may  imbed  product 
information  differently,  and  some  data  may  become  lost  when 
the  IGES  file  is  read  by  the  post-processor.  Application 
validation  testing  checks  a  translators  capability  to  support 
the  specific  application  protocols.  Application  protocols  are 
concerned  with  both  the  manner  in  which  an  IGES  file  is 
constructed  and  with  the  intended  meaning  of  the  entities 
used.  For  a  particular  application  protocol  only  certain 
entities  are  permitted  to  be  used  and  these  entities  will  have 
a  definite  meaning  within  that  particular  application 
protocol.  The  same  entities,  when  used  in  a  different 
application  protocol,  may  be  assigned  a  different  meaning  (or 
interpretation) . 

Application  validation  testing  checks  whether  a 
translator  is  capable  of  translating  all  entities  required  for 
a  specific  application.  Whereas,  verification  testing  only 
checks  whether  a  translator  is  capable  of  accurately 
translating  entities  that  the  developer  claims  to  translate 
without  regard  to  whether  the  translator  can  satisfy  a  given 
application. 


1.4.6  CALS  TEST  NETWORK 

The  CALS  Test  Network  (CTN)  was  established  to  test  the 
exchange  of  digital  product  definition  data  using  MIL-D-1840A, 
and  to  recommend  changes  to  that  document.  The  testing  will 
start  with  the  following  standards:  MIL-D-28000  Representation 
for  the  Communication  of  Product  Data,  IGES  Application 
Subsets;  MIL-M-28001  Markup  Requirements  and  Generic  Style 
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Specification  for  Electronic  Printed  Output  and  Exchange  of 
Text  (SGML) ;  MIL-R-28002  Raster  Graphics  Representation  in 
Binary  Format,  Requirements  for;  and  MIL-D-28003  Digital 
Representation  for  Communication  of  Illustration  Data:  CGM 
Application  Profile.  The  testing  is  directed  by  the  Air  Force 
Logistics  Command  and  performed  by  Lawrence  Livermore  National 
Laboratories,  the  military  services  and  volunteer  companies. 

The  CTN  will  test  the  current  CALS  data  interchange 
standards,  but  is  not  trying  to  specifically  test  whether  the 
software  systems  used  (e.g.,  translators)  conform  to  the  CALS 
standards.  The  purpose  of  the  network  is  to  "evaluate  the 
effectiveness  of  CALS  standards  for  data  interchange"  and 
"demonstrate  the  effectiveness  and  benefits  of  employing 
digital  data  exchange  rather  than  paper  copy".  The  tests  used 
will  be  end-to-end  tests,  under  actual  conditions  and 
structured  tests.  The  results  that  have  been  reviewed  and 
approved  by  the  CTN  will  be  available  on  the  CALS  bulletin 
board  for  public  view. 


1 . 5  FLAVORING 

In  an  ideal  situation  translators  would  be  capable  of 
transmitting  data  between  two  different  software  systems  via  a 
neutral  file  without  any  concern  as  to  which  sending/ receiving 
system  was  involved  in  the  transfer.  In  actual  practice  however, 
as  in  the  case  of  IGES,  all  translators  do  not  support  the  entire 
neutral  file  standard  and  the  specification  permits  more  than  one 
way  to  represent  an  entity.  Since  the  IGES  specification  is 
ambiguous,  each  vendor's  interpretation  and  implementation  of  the 
standard  may  differ.  As  a  result,  knowledge  of  the  sending  and 
receiving  system  as  well  as  the  vendor's  interpretation  of  the 
specification  is  useful  to  ensure  complete  and  accurate  data 
transfer.  Flavoring  is  the  term  used  to  describe  modifying  an  IGES 
data  file  and  producing  a  new  IGES  file  tailored  for  the 
capabilities  of  a  specific  CAD/CAM  systems'  IGES  processor.  There 
is  often  more  than  one  way  to  represent  an  entity  in  an  IGES  file. 
For  example,  a  surface  could  be  a  Parametric  Spline  Surface,  B- 
Spline  Surface,  Ruled  Surface,  Tabulated  Cylinder,  or  Surface  of 
Revolution  in  an  IGES  file.  The  representation  usually  depends  on 
what  the  entity  was  in  the  native  database.  All  IGES  translators 
do  not  support  all  of  the  entities  in  the  IGES  specification.  IGES 
files  are  said  to  come  in  many  different  "flavors",  because  of  the 
many  different  entities  and  forms  numbers  available  for 
representing  an  object  in  the  IGES  format. 

Since  the  translators  do  not  support  all  of  the  entities  in 
the  IGES  specification,  either  in  their  translators  or  in  their 
internal  database  an  IGES  file  is  created  that  has  a  specific  CAD 
systems'  flavor.  For  example,  a  sending  CAD  system's  IGES  pre¬ 
processor  may  only  be  capable  of  writing  a  particular  internal 


entity  to  only  one  IGES  entity  type  in  the  IGES  file.  Another  CAD 
system's  IGES  post-processor  may  not  be  able  to  read  that  specific 
entity  type,  sometimes  even  if  it's  available  within  the  CAD 
system.  As  a  result,  without  flavoring,  the  two  systems  will  be 
capable  of  exchanging  only  the  IGES  entities  common  to  both  CAD 
systems,  as  illustrated  in  Figure  5. _ 
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Figure  5  Overlap  of  Entities 


Even  if  both  CAD  systems  support  an  entity  there  still  can 
be  problems.  For  example,  many  CAD  systems  use  layering,  where 
entities  can  be  grouped  together  and  stored  with  each  grouping  of 
entities  called  a  layer.  Each  layer  may  be  displayed 
individually  or  as  a  composite  overlay  to  display  or  hide  parts 
of  the  model.  Two  CAD  systems  may  support  layering  differently. 
System  A  may  allow  255  layers,  (layers  1  to  255) .  System  B  may 
allow  1029  layers,  (layers  0  to  1028).  If  system  B  sent  system  A 
an  IGES  file  with  entities  on  every  layer,  system  A's  IGES  post¬ 
processor  would  have  to  move  the  entities  that  were  on  layers  0, 
and  layers  256  through  1028  to  new  layers  understandable  to  system 
A.  The  scheme  the  translator  uses  might  be  unsuitable  for  a  given 
application.  For  example,  the  translator  may  put  all  of  the 
entities  from  layer  0  and  layers  256  through  1028  on  system  B  onto 
the  same  single  layer  on  system  A. 

One  way  to  cope  with  this  problem  is  to  use  flavoring  software 
to  convert  IGES  entities  from  one  entity  type  to  another,  or 
otherwise  manipulate  the  IGES  file,  as  shown  in  Figure  6.  Many  IGES 
pre-processors  have  some  flavoring  capabilities  built  into  them. 
They  offer  a  choice  of  the  IGES  entity  type  that  a  specific 
internal  CAD  entity  will  be  written  to  in  the  IGES  file.  This 
requires  some  knowledge  by  the  sending  system's  user  of  what  the 
receiving  CAD  system  can  post  process,  before  he  can  decide  upon 
the  entity  types  that  should  be  in,  the  IGES  file.  One  point  about 
flavoring  software  that  should  be  kept  in  mind  is  that  it  does 
modify  the  IGES  file.  If  an  error  in  translation  is  found  in  a 
file  that  has  been  altered  using  a  flavorizer,  then  the  flavorizer 
must  also  be  checked  as  a  possible  source  of  the  error. 
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Figure  6.  Flavoring  Software 


The  Department  of  Energy  has  developed  the  DOEDEF  (Department 
of  Energy  Data  Exchange  Format)  software  package  which  will  shorten 
the  time  required  to  develop  flavoring  software.  The  DOEDEF 
software  tool  facilitates  developing  user-written  IGES  flavor 
translators  by  performing  file  maintenance  tasks  as  the  database 
containing  IGES  entities  is  modified.  When  a  new  IGES  file  is 
output,  the  "housekeeping"  details  of  the  IGES  file,  such  as 
pointers  and  sequence  numbers,  are  automatically  updated.  A  tool 
like  DOEDEF  is  helpful  when  writing  a  flavor  translator,  but  the 
programs  to  change  IGES  entities  from  one  entity  type  to  another 
entity  type  must  still  be  written. 


1.6  INITIAL  GRAPHICS  EXCHANGE  SPECIFICATION  (IGES) 

The  Initial  Graphics  Exchange  Specification  (IGES)  was 
initiated  in  1979  by  a  small  group  composed  of  representatives  from 
Boeing,  General  Electric  and  the  National  Institute  of  Standards 
and  Technology  (NIST,  formerly  the  National  Bureau  of  Standards) . 
The  first  version  of  IGES  was  published  in  1980  and  approved  by  the 
American  National  Standards  Institute  (ANSI)  in  1981  as  a  national 
standard.  Version  2.0  of  IGES  was  published  in  1983  (but  was  not 
issued  as  a  national  standard) .  NIST  published  the  IGES  version 
3.0  specification  in  April,  1986.  The  IGES  3.0  specification  was 
approved  by  ANSI  as  ANSI  Y14.26M  and  is  the  current  national 
standard.  The  standard  describes  a  file  format  to  allow  the 
communication  of  "the  data  required  to  describe  and  communicate  the 
essential  engineering  characteristics  of  physical  objects  as 
manufactured  products."  It  is  composed  of  units  of  information 
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called  entities,  both  geometric  and  non  geometric,  that  are  linked 
together  in  a  sequential  file  to  describe  a  CAD  model.  A  summary 
of  the  IGES  entities  in  the  3.0  document  are: 


-  surfaces:  parametric,  b-spline,  offset,  trimmed, 
ruled,  surface  of  revolution,  tabulated  cylinder,  etc. 

-  curves:  lines,  circles,  conics,  b-splines,  etc. 

-  points:  normal  point,  connect  point 

-  annotation:  angular,  diameter,  ordinate  point  and  radius 
dimensions,  symbols,  notes  and  labels,  etc. 

-  structure:  groups 

-  external  file  references  for  libraries  of  components  or 
symbols 

-  finite  element  modeling  data 

-  electronic  printed  wiring  board  data 

-  text  fonts 


IGES  4.0  was  published  in  April,  1988  and  has  been  submitted 
to  the  American  National  Standards  Institute  (ANSI)  for  approval 
as  a  national  standard.  The  major  additions  to  version  4.0  are 
Constructive  Solid  Geometry  (CSG)  solids,  parameters  for  electrical 
products  and  the  concept  of  "gray”  pages.  "Gray"  pages  are  the 
section  of  the  document  that  holds  new  untested  entities.  These 
entities  are  removed  from  the  gray  pages  and  put  into  the  main 
portion  of  the  specification  when  three  production  translators 
support  that  entity.  IGES  5.0  is  scheduled  for  publication  in  July 
1990,  and  will  contain  boundary  representation  (BREP)  solids. 

The  IGES  organization  has  published  a  Recommended  Practices 
Guide  to  aid  the  implementers  and  users  of  IGES.  It  suggests 
interpretations  of  the  specification  for  the  complex,  or  ambiguous 
sections  and  fills  in  omissions  in  the  specification.  Many  of  the 
recommendations  proposed  in  the  guide  that  clarify  an  omission  or 
ambiguity  in  the  specification  are  later  incorporated  in  the  next 
version  of  IGES.  An  example  of  this  is  the  delimiter  for  separating 
fields.  In  version  3.0  there  were  no  limits  on  what  the  character 
for  a  delimiter  could  be.  A  recommended  practice  was  issued 
disallowing  the  use  of  control  characters,  space,  numbers,  and  a 
few  other  common  symbols  usually  used  as  data  in  the  file,  for  a 
delimiter.  This  restriction  was  then  incorporated  into  IGES  4.0. 
The  current  version  of  the  Recommended  Practices  Document  is  4.0, 
released  in  March  1988. 
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1.7  APPLICATION  SUBSETS  AND  PROTOCOLS 


The  IGES  specification  is  a  large,  (170  entities  in  version 
4.0),  and  complex  specification  with  various  choices  on  the  type 
of  IGES  entity  that  a  CAD  model  entity  could  be  translated  into. 
As  a  result,  software  vendors  seldom  support  every  entity  in  the 
specification,  but  support  a  subset  of  the  specification  that  best 
matches  the  features  of  their  CAD  system.  Invariably,  there  is  a 
mismatch  between  the  set  of  entities  utilized  by  one  CAD  systems 
pre-processor  and  another  CAD  systems  post-processor.  Many  times 
the  intersection  of  the  supported  entities  is  adequate  for  data 
transfer,  but  not  in  all  cases.  So,  the  entities  needed  may  not 
transfer  completely.  As  a  result,  the  statement  "I  support  IGES 
version  4.0"  by  a  vendor,  should  be  interpreted  as  the  particular 
vendor  supports  an  assortment  of  version  4.0  entities,  but  most 
likely  not  all  of  the  entities. 

Application  Subsets  are  the  initial  approach  to  overcoming 
the  incompatibility  of  CAD  systems  as  a  result  of  mismatching 
entity  support.  They  are  intended  to  divide  the  IGES  manual  into 
brief,  related  portions.  This  informs  the  user  about  the  type  of 
entities  to  expect  in  an  IGES  file  that  conforms  to  an  application 
subset.  An  application  subset  is  developed  by  identifying  an 
application  area,  for  example  Technical  Illustrations.  The  IGES 
entities  used  by  that  application  are  identified  as  a  subset.  A 
file  conforming  to  the  subset  may  use  only  the  entities  specified 
in  that  subset  for  product  definition.  As  stated  by  MIL-D-28000, 
other  entities  may  be  present  in  the  file  if:  they  are  valid  IGES 
entities;  not  necessary  for  the  product  data  description;  or  are 
just  for  regenerating  the  same  development  environment  on  the  CAD 
system  that  originally  developed  the  file.  Following  these  rules 
the  receiving  system  can  reject  the  "volunteer"  entities  without 
causing  a  negative  effect  on  the  transfer.  The  concept  of 
application  subsets  lets  a  user  specify  the  particular  type  of  IGES 
file  he  wants  to  exchange. 

As  defined  by  IEEE,  a  protocol  is  a  set  of  conventions  or 
rules  that  govern  the  operation  of  functional  units  to  achieve 
communication.  Application  Protocols  are  the  next  logical  step 
from  application  subsets,  because  protocols  provide  both  a  subset 
of  entities  and  what  those  entities  mean  or  represent  within  the 
application  protocol,  as  shown  in  Figure  7  (page  18).  The 
protocols  are  created  by  modeling  the  application  area's 
information  requirements  using  an  information  analysis  modeling 
methodology.  Based  on  the  models,  the  application  area  experts 
decide  what  IGES  entities  would  best  carry  the  required 
information. 
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Figure  7.  Relationship  between  subsets  and  protocols 


The  IGES/PDES  Application  Validation  Methodology  Committee 
(AVM)  is  working  on  refining  the  definition  of  application 
protocols.  They  are  working  with  other  IGES/PDES  technical 
committees  to  create  the  Technical  Publications  Application 
Protocol,  the  Engineering  Drawings  Application  Protocol,  the  3-D 
Piping  Application  Protocol  and  the  Electrical  Products  Application 
Protocol.  MIL-D-28000  reveals  an  interest  in  application 
protocols;  Section  6.1,  states  "It  is  the  intent  of  this 
specification  to  evolve  in  the  direction  of  application  protocols 
to  ensure  quality  data  exchanges". 

An  example  of  an  application  protocol  would  be  the  draft  3-D 
Piping  IGES  Application  Protocol,  which  describes  the 
representation  and  exchange  of  3-D  piping  models  for  the 
arrangement  of  piping  and  pipe-connected  equipment.  A  portion  of 
the  protocol  discusses  the  representation  of  a  pipe.  Pipes  are 
represented  by  composite  curve  entities,  which  contain  lines,  arcs 
and  connect  points.  The  line  represents  a  straight  part  of  the 
pipeline,  a  circular  arc  represents  a  curved  portion  of  the 
pipeline  or  elbow,  and  the  connect  point  represents  either  a 
start/stop  on  a  pipe  or  a  component  connect.  If  these  entities 
were  transferred  without  using  the  protocol,  the  wire  frame  data 
would  be  received  without  information  on  its  meaning.  But  if  these 
entities  were  passed  using  the  3-D  piping  application  protocol  to 
an  IGES  post  processor  that  supports  this  application  protocol, 
then  the  idea  that  the  composite  curve  represents  a  pipe  can  be 
understood  by  the  translation  software  and  the  CAD  system.  The  goal 
of  application  protocols  is  to  allow  more  transfer  of  objects 
instead  of  merely  a  wire  frame  representation  of  lines,  arcs,  and 
points  with  no  intelligence  attached.  In  other  words,  the  tendency 
is  toward  product  definition  rather  than  drawings. 
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1.8  PRODUCT  DATA  EXCHANGE  SPECIFICATION  (PDES) 

PDES  is  a  specification  currently  under  development  for  the 
exchange  of  complete  product  data  in  a  computer  sensible  format. 
Product  data  in  its  fullest  sense  is  the  data  needed  to  design, 
manufacture  and  support  a  product  through  its  life-cycle.  Product 
Data  includes  product  definition  data  (the  data  elements  required 
to  completely  define  a  product)  and  the  additional  elements 
required  for  reliability  and  maintainability.  PDES  is  being 
developed  by  the  IGES/PDES  Organization  with  participation  from  the 
International  Standards  Organization  (ISO) . 

The  International  Standards  Organization  (ISO)  approved  the 
PDES  document  submitted  for  ISO  registration  in  November,  1988,  as 
a  formal  Draft  Proposal.  The  document  submitted  to  ISO  contains 
data  models  which  can  describe  only  a  subset  of  the  product  data 
required  to  represent  a  given  product  and  is  intended  to  permit 
international  review  and  to  serve  as  a  check  point  for  the  PDES 
development  effort.  The  ISO  registration  does  not  imply  approval 
of  its  content,  but  does  begin  the  international  balloting  that 
will  produce  consensus  approval  of  the  specification.  The  final 
stages  of  ISO  standardization  are  the  elevation  of  the  Draft 
Proposal  to  the  status  of  a  Draft  International  Standard  (earliest 
possible  date  January  1990)  and  finally  to  an  International 
Standard  (earliest  possible  date  January  1991).  PDES  version  1.0 
will  be  a  subset  of  the  Draft  Proposal  and  will  be  known  as  STEP 
(Standard  for  the  Exchange  of  Product  Data)  once  it  is  approved  by 
ISO.  STEP  will  be  the  actual  standard,  approved  by  the 
international  standards  making  body.  While,  PDES  is  the 
specification  that  is  being  developed  in  the  U.S.  and  submitted  for 
approval  as  STEP.  The  intent  is  for  PDES  and  STEP  to  be  identical. 

PDES,  Inc.  was  formed  in  April  1988  to  accelerate  the 
development  of  the  PDES.  The  members  of  the  non  profit  group  are 
Boeing,  General  Dynamics,  General  Electric,  Grumman,  Lockheed, 
McDonnell  Douglas,  Northrop,  DEC,  FMC,  IBM,  Prime/Computervision, 
LTV,  Rockwell,  Martin  Marietta,  General  Motors,  Newport  News 
Shipbuilding  and  Westinghouse,  and  NIST  participates  as  a 
Government  Associate.  These  companies  provide  the  technical 
resources  and  personnel  needed  by  the  program  with  general 
management  furnished  by  the  South  Carolina  Research  Authority 
(SCRA) .  Phase  I  of  the  PDES  Inc.  program  focuses  on  the  validation 
and  implementation  of  the  PDES/STEP  Draft  Proposal  mechanical  parts 
subset.  PDES,  Inc.  is  organized  into  three  technical  areas: 
modeling  and  integration,  testing  and  validation,  and  technical 
products/ implementation.  Phase  II  will  broaden  the  scope  to  include 
electronic  components  and  assemblies. 

The  IGES  and  PDES  specifications  will  be  developed  in  parallel 
until  PDES  can  be  used  in  production  data  exchange  with  similar 
capabilities  to  the  current  IGES  standard.  An  informal  poll  of  the 
vendors  in  the  IGES/PDES  Implementers  Committee  during  the  January 
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1989  meeting,  concluded  that  they  will  not  have  PDES  translators 
with  capability  comparable  to  the  current  IGES  translators  for 
approximately  five  years.  Current  IGES  translators  are  capable  of 
transferring  some  product  data  (e.g.,  the  SEAWOLF  digital  data 
exchange  project  has  demonstrated  the  capability  to  transfer 
structural  data  using  IGES  translators) .  In  the  interim,  an  IGES 
version  6.0  is  anticipated,  but  the  scope  has  not  yet  been  defined. 


1.9  ELECTRONIC  DATA  INTERCHANGE  (EDI) 

The  Government  and  Industry  process  large  amounts  of  paper 
for  business  purposes.  A  sizable  portion  of  this  involves 
transactions  external  to  the  firm  for  business  related  documents. 
These  documents  include  purchase  orders,  invoices,  sales 
price/sales  catalogs,  shipping  notices/manifest,  contracting 
documents,  etc.  These  documents  may  be  created  on  computer 
systems,  but  usually  cannot  be  sent  to  the  intended  outside 
organization  electronically  because  of  the  different  computer 
system  format  needed  by  the  receiving  organization.  If  the  group 
that  receives  the  document  tracks  or  processes  it  electronically, 
then  it  must  be  re-entered  on  the  computer,  which  in  turn  delays 
the  turn  around  time  of  the  transaction. 

Electronic  Data  Interchange  (EDI),  ANSI  ASC  X12,  is  a  standard 
for  automatic  computer  to  computer  interchange  of  data  used  in 
business  transactions.  It  provides  a  standard  format  that  the 
business  data  in  computer  data  bases  can  be  translated  into  for  the 
transmittal  of  the  EDI  formatted  data  to  another  organization. 
Using  the  EDI  format  the  data  is  automatically  translated  into  a 
receiving  systems  data  base.  Implementations  of  the  EDI  standard 
eliminate  the  need  to  re-enter  business  data. 

The  Deputy  Secretary  of  Defense  announced  on  May  24th,  1988 
that  EDI  will  be  used  as  the  DoD  standard  for  electronic  data 
interchange.  The  Director,  Defense  Logistics  Standard  Systems 
Office  (DLSSO)  is  responsible  for  providing  information  support  to 
DoD  in  using  EDI  and  representing  the  DoD  needs  to  EDI  standards 
making  bodies.  The  services  have  designated  representatives  to 
serve  on  a  Joint  Service/ Agency  Logistics  EDI  committee  and  program 
project  teams,  and  will  be  responsible  for  implementing  approved 
EDI  standards. 

EDI  is  not  yet  a  CALS  standard.  But,  work  is  underway  to 
include  Electronic  (business)  Data  Interchange  transactions  to 
support  CALS  technical  information  as  a  future  CALS  standard.  A 
proposed  -xtension  to  the  ANSI  X12  standard  will  be  used  to  define 
a  MIL-STD-1840A  compatible  transaction  set  for  enveloping  CALS  data 
within  an  EDI  transaction. 
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2.0  CALS  STANDARDS  OVERVIEW 


Standards  and  specifications  are  being  developed  by  CALS 
to  provide  the  common  interfaces  needed  to  improve  Industry  and  DoD 
productivity  and  quality  in  both  acquisition  and  logistic  support 
in  the  interchange  and  efficient  use  of  digital  data.  CALS  phase 
I  focuses  on  standards  for  digital  interchange  of  technical 
information  among  dissimilar  computer  systems.  Initial  CALS 
standards  are  intended  to  enable  the  digital  delivery  of 
engineering  drawings  and  technical  manuals  including  illustrations. 
CALS  phase  II  focuses  on  the  standards  needed  to  access  and  manage 
data  within  a  distributed  data  base.  MIL-HDBK-59,  Computer-Aided 
Acquisition  and  Logistic  Support  (CALS)  Program  Implementation 
Guide,  is  DoD's  guidance  document  for  the  implementation  of  CALS. 
Each  service  is  responsible  for  issuing  implementation  guidance  of 
their  own.  MIL-HDBK-59  provides  an  overview  of  CALS  and  provides 
guidance  on  the  use  and  delivery  of  digital  data.  Under  that 
standard  lies  MIL-STD-1840A,  Automated  Interchange  of  Technical 
Information,  which  provides  technical  information  on  the 
specifications  used  in  CALS,  the  packaging  of  the  digital  form,  and 
basic  concepts. 


Current  CALS  data  exchange  standards/ specifications  are: 

1.  MIL-STD-1840A,  "Automated  Interchange  of  Technical 
Information" 

2.  MIL-D-28000 ,  "Digital  Representation  for  Communication 
of  Product  Data:  IGES  Application  Subsets" 

3.  MIL-M-28001 ,  "Markup  Requirements  and  Generic  Style 
Specification  for  Electronic  Printed  Output  and 
Exchange  of  Text" 

4.  MIL-R-28002 ,  "Requirements  for  Raster  Graphics 

Representation  in  Binary  Format" 

5.  MIL-D-28003 ,  "Digital  Representation  for  Communication 
of  Illustration  Data:  CGM  Application  Profile" 
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Future  standards  will  address  data  interchange  in  terms  of 
both  technical  data  elements  and  the  life  cycle  functional 
applications  that  use  the  technical  data.  Future  CALS  data  exchange 
standards  are  likely  to  include: 

6.  MIL-STD-1388-2B,  Logistic  Support  Analysis  Record 

7.  PDES ,  Product  Data  Exchange  Specification 

8.  EDIF,  Electronic  Data  Interchange  Format 

9.  VHDL,  VHSIC  Hardware  Description  Language 

10.  ODA,  Office  Document  Architecture 
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2.1  AUTOMATED  INTERCHANGE  OF  TECHNICAL  INFORMATION 

(MIL-STD-1840A) 

2.1.1  PURPOSE 

MIL-STD-1840A  is  the  "parent"  standard  for  a  family  of 
military  specifications  known  as  the  CALS  standards.  It 
describes  the  digital  data  files  for  a  complete  deliverable 
with  respect  to  CALS  standards  MIL-D-28000  (IGES,  for  computer 
aided  design  vector  graphics) ,  MIL-M-28001  (SGML,  for  text) , 
MIL-R-28002  (for  raster  scanned  images),  and  MIL-D-28003  (CGM, 
for  technical  illustration  vector  graphics) .  Its  purpose  is 
to  standardize  the  digital  interface  between  systems 
exchanging  digital  forms  of  technical  information  necessary 
for  the  logistic  support  of  weapon  systems.  It  governs  the 
interchange  of  digital  technical  information  and  specifies  the 
media,  procedures,  labels,  identifying  data,  and  standards  for 
transfer  of  various  types  of  technical  information. 

The  format,  information  structures,  and  transfer 
procedures  established  in  MIL-STD-1840A  are  applicable  in  all 
cases  where  information  is  prepared,  transmitted,  and  received 
in  the  form  of  ASCII  text  files,  product  definition  data 
files,  raster  image  files,  or  graphics  files.  MIL-STD-1840A 
does  not  restrict  any  current  applications.  In  other  words, 
it  is  intended  as  a  single  source  for  describing  digital  data 
files  needed  to  exchange  data  between  organizations/computers. 


2.1.2  TYPICAL  APPLICATIONS 

MIL-STD-1840A  addresses  technical  publications  (such  as 
training  manuals,  technical  manuals  with  associated  figures, 
etc.),  product  definition  data  (such  as  engineering  drawings, 
etc . ) ,  and  the  evolving  product  data  concept  which  provides 
for  transfer  and  archival  storage  of  technical  data. 


2.1.3  SCOPE 

MIL-STD-1840A  covers  two  types  of  documents  delivered  in 
digital  form:  Technical  Publications  and  Product  Data. 


2. 1.3.1  TECHNICAL  PUBLICATIONS 

The  text  and  illustrations  of  technical  publications 
shall  be  organized  into  "file  sets"  which  are  collections  of 
files  containing  the  complete  publication.  Figure  8  (page  26) 
illustrates  file  sets  on  a  MIL-STD-1840A  tape.  The  data  shall 
be  "encoded"  in  the  format  described  below  as  specified  by  the 
contract  requiring  the  data.  The  data  file  header  records 


shall  accompany  the  file  set.  A  declaration  file  which 
uniquely  identifies  the  document  being  delivered  shall  be 
included  in  the  file  set.  The  file  sets  which  comprise  a 
publication  shall  be  in  one  of  the  following  forms: 

a.  A  raster  page  image  file  set  shall  consist  of 
a  declaration  file  and  the  actual  (raster  page  image) 
files.  Each  file  shall  be  accompanied  by  data  file 
header  records. 

b.  A  page  description  language  (PDL)  file  set  shall 
consist  of  a  declaration  file  and  the  PDL  files  as 
specified  by  the  contract.  Each  file  shall  be  accompanied 
by  data  file  header  records. 

c.  An  SGML  (Standard  Generalized  Markup  Language) 
"Conforming”  file  set  shall  consist  of  the  following:  a 
declaration  file;  the  SGML-coded  text  files  with 
accompanying  data  file  header  records;  and  the 
illustration  data  files  in  IGES  (Initial  Graphics 
Exchange  Specification,  in  accordance  with  MIL-D-28000) , 
raster  (in  accordance  with  MIL-R-28002) ,  and/or  CGM 
(Computer  Graphics  Metafile,  in  accordance  with 
MIL-D-28003)  format  with  accompanying  data  file  header 
records.  The  term  "conforming"  means  that  the  SGML-coded 
text  file  and  the  output  specification  conform  to 
MIL-M-28001 . 

d.  An  SGML  "Non-conforming"  file  set  shall  consist 
of  the  following:  a  declaration  file;  the  SGML-coded  text 
files  with  accompanying  data  file  header  records;  the 
illustration  data  files  in  IGES,  raster,  and/or  CGM 
format  with  accompanying  data  file  header  records;  the 
Document  Type  Definition  (DTD)  data  file  with 
accompanying  data  file  header  records;  and  the 
non-conforming  output  specification  data  file  with 
accompanying  data  file  header  records.  The  term  "non- 
conforming  in  this  context  means  that  the  publication 
being  delivered  was  developed  in  accordance  with  military 
specifications  other  than  those  cited  in  MIL-M-28001. 
MIL-M-28001  provides  guidelines  for  the  development  of 
a  DTD  and  Output  Specification  appropriate  for  such  a 
publication. 
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Figure  8.  MIL-STD-1840A  Tape  Example 


The  technical  publications  listed  above  must  be  in 
the  following  format: 

The  declaration  file  shall  uniquely  identify  the 
technical  publication,  and  its  format  shall  be  7-bit 
ASCII.  The  text  source  file  shall  consist  of  SGML-coded 
text  files  in  accordance  with  MIL-M-28001  in  ASCII 
format.  The  document  type  definition  file  format  shall 
define  the  structure  and  content  of  the  SGML-coded  text 
file  in  accordance  with  MIL-M-28001.  The  output 
specification  file  shall  define  the  style  and  format  of 
the  SGML-coded  text  file  in  accordance  with  MIL-M-28001. 
An  illustration  data  file  shall  be  in  IGES,  raster,  or 
CGM  format.  Each  illustration  in  the  technical 
publication  shall  be  supported  by  an  illustration  data 
file,  except  for  repeated  instances  of  the  same 
illustration.  Each  illustration  data  file  shall  be 
accompanied  by  identifying  header  records. 


2. 1.3. 2  PRODUCT  DATA 

MIL-STD-1840A  defines  product  data  as  being  all  those 
data  elements  necessary  to  define  the  geometry,  function,  and 
behavior  of  a  "part"  over  its  entire  lifespan  as  well  as 
additional  logistics  elements  for  reliability  and 
maintainability.  MIL-STD-1840A  currently  requires  product  data 
be  in  IGES  or  raster  format  as  specified  by  contract 
(obviously  this  will  limit  the  product  data  which  can  be 
transferred  until  PDES  becomes  a  part  of  the  standard) .  The 
files  of  a  Product  Data  document  shall  consist  of  the 
following: 

A  declaration  file  in  7  bit  ASCII  format  to  uniquely 
identify  the  document;  engineering  drawing  data  files  in 
IGES  or  raster  accompanied  by  identifying  header  records; 
electrical/electronic  application  data  files  (in 
accordance  with  MIL-D-28000)  accompanied  by  identifying 
header  records;  or  numerical  control  manufacturing  data 
files  (in  accordance  with  MIL-D-28000)  accompanied  by 
identifying  header  records. 


2.1.4  FILE  STRUCTURE  FOR  TRANSFER 

A  document  to  be  interchanged  shall  consist  of  a 
declaration  file  and  at  least  one  data  file.  The  declaration 
file  shall  precede  the  document's  data  files.  If  several 
documents  are  to  be  interchanged,  all  declaration  files  shall 
be  collected  at  the  beginning  and  the  document  file  groups 
shall  follow  the  declaration  files  consecutively. 
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A  declaration  file  provides  information  about 
identifiers,  source,  destination,  classification,  etc.  of  the 
document.  The  declaration  file  also  tells  how  many  files  are 
in  the  file  sets  which  make  up  the  complete  document. 

A  data  file  type  is  one  of  the  following:  textual  file, 
DTD  file,  output  specification  file,  IGES  file,  raster  file, 
CGM  file,  special  word  file,  PDL  file,  or  Gray  Scale  data 
file. 


Identifying  header  records  shall  accompany  a  data  file. 
A  record  identifier  shall  be  the  first  characters  in  a  record; 
a  colon  and  a  space  character  shall  terminate  the  record 
identifier  string.  For  example,  a  textual  data  file  header 
record  shall  contain  the  following  information:  source  system 
document  identifier,  destination  system  document  identifier, 
text  file  identifier,  figure  identifier,  source  graphics 
filename,  data  file  security  label,  and  notes. 


2.1.5  TRANSFER  MEDIA 

Either  of  the  following  transfer  media  can  be  used: 

2. 1.5.1  Magnetic  Tape  -  Tape  format  shall  be 

written  in  accordance  with  FIPS  PUB  79. 
1600  and  6250  CPI  (only  on  9-track  tapes) 
are  acceptable  in  accordance  with  FIPS 
PUBS  25,  50,  and  79.  Multi-volume  tapes 
are  also  acceptable. 


2. 1.5. 2  Optical  Disk  -  The  format  of  optical  disk 
data  shall  be  specified  by  the  contract. 


2.1.6  PROBLEMS  AND  LIMITATIONS  WITH  CURRENT  SPECIFICATIONS 

Future  revisions  on  MIL-STD-1840A  will  address  product 
data  files  in  "IPC"  (Integrated  Printed  Circuits)  ,  ''VHDL” 
(VHSIC  Hardware  Description  Language)  ,  "EDIF"  (Electronic  Data 
Interchange  Format) ,  and  nPDES"  (Product  Data  Exchange 
Standard)  format. 

MIL-STD-1840A  does  not  yet  exploit  emerging 
computer-based  technologies  such  as  solid  modeling  for  system 
design,  the  interactive  retrieval  and  use  of  technical 
information,  or  expert  systems.  It  is  envisioned  that  as  these 
applications  become  more  mature,  MIL-STD-1840A  will  be 
extended  to  apply. 

i 
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2.1.7  EXTENT  AND  NATURE  OF  USER  AND  VENDOR  SUPPORT 


The  extent  of  the  use  of  MIL-STD-1840A  today  depends  upon 
the  use  of  the  standards  of  interchange  which  MIL-STD-1840A 
specifies.  The  CALS  Test  Network  (CTN)  was  established  to 
perform  end-to-end  testing  of  the  exchange  of  digital  product 
definition  data  using  MIL-STD-1840A.  "CALS-compliant"  systems 
must  have  the  capability  of  reading  and  generating  tapes 
conforming  to  MIL-STD-1840A. 


2.1.8  REFERENCE  AND  IMPLEMENTATION  DOCUMENTS 

MIL-STD-1840A  references  the  current  suite  of  CALS 
standards.  In  addition,  a  "CALS  Program  Implementation  Guide" 
(MIL-HDBK-59 )  has  been  developed  to  provide  information  and 
guidance  to  personnel  responsible  for  the  acquisition  and  use 
of  weapon  system  technical  data. 


29 


2.2  DIGITAL  REPRESENTATION  FOR  COMMUNICATION  OF  PRODUCTION 

DATA:  IGES  APPLICATION  SUBSETS  (MIL-D-28000) 

2.2.1  PURPOSE 

MIL-D-28000  is  a  DoD  standard  for  the  digital 

representation  of  product  definition  data  using  the  Initial 

Graphics  Exchange  Specification  (IGES)  application  subsets. 
IGES  is  a  neutral  format  for  digital  interchange  of  product 

definition  data  between  dissimilar  computer  aided  design 

systems.  The  current  standard  has  four  defined  subsets: 

Class  I:  Technical  Illustrations 

Class  II:  Engineering  Drawings 

Class  III:  Electrical/Electronic  Applications 

Class  IV:  Numerical  Control  Manufacturing 

The  subsets  are  composed  of  entities  from  ANSI  Y14.26M,  the 
Digital  Representation  for  Communication  of  Product  Definition 
Data,  (equivalent  to  IGES  Version  3.0),  with  a  few  entities 
from  IGES  version  4.0,  such  as  the  unbounded  plane  (108  form 
0)  .  A  MIL-D-28000  file  must  use  one  of  the  four  approved 
subsets,  indicating  the  specific  subset  used  in  the  beginning 
of  the  file  (IGES  start  section) . 


2.2.2  SCOPE 

MIL-D-28000  specifies  four  defined  subsets  of  the  IGES 
standard  (technical  illustrations,  engineering  drawings, 
electrical/electronics  applications,  and  numerical  control 
manufacturing)  as  opposed  to  the  entire  IGES  standard.  The 
reason  for  this  is  the  IGES  specification  is  large  and 
complex,  with  different  options  that  may  be  used  to  represent 
the  same  Computer  Aided  Design  (CAD)  model  entity.  As  a 
result,  software  vendors  seldom  support  every  entity  in  the 
specification,  but  support  a  subset  of  the  specification  that 
best  matches  the  features  of  their  CAD  system.  Invariably, 
there  is  a  mismatch  between  the  set  of  entities  utilized  by 
one  CAD  systems  pre-processor  and  another  CAD  systems  post¬ 
processor.  There  is  no  guarantee  that  the  intersection  of  the 
supported  entities  is  adequate  for  the  required  data  transfer. 

MIL-D-28000  specifies  only  the  entities  needed  for  a 
specific  application.  In  this  way  the  recipient  of  a  MIL-D- 
28000  data  file  may  specify  the  class  of  data  he  needs  without 
becoming  an  expert  on  the  IGES  manual  or  the  entities 
supported  by  various  vendor  translators.  The  only  other 
entities  allowed  in  the  file  are  "volunteer"  entities.  As 
stated  by  MIL-D-28000,  "volunteer"  entities  must  be: 
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a.  valid  Y14.26M  entities, 

b.  not  necessary  for  the  product  data 
representation,  and 

c.  meant  only  for  restoring  the  environment  on 
the  CAD  system  that  originally  developed  the 
file  for  transmittal. 

These  requirements  will  ensure  that  the  CAD  system  that 
receives  the  file  will  not  lose  any  of  the  product  information 
if  it  does  not  transfer  the  "volunteer”  entities. 


2.2.3  STATUS  AND  PLANNED  EXTENSIONS 

MIL-D-28000  is  based  upon  an  underlying  American 
National  Standards  Institute  standard  (ANSI  Y14.26M, 

IGES  version  3.0).  As  such,  there  is  cooperation  between  the 
CALS  office  and  the  voluntary  IGES/PDES  group  through  the 
auspices  of  the  National  Institute  of  Standards  and  Technology 
(NIST) .  NIST  coordinates  the  work  towards  resolution  of 
technical  comments  beyond  the  expertise  of  the  CALS  office  and 
works  towards  any  viable  requested  changes  or  extensions  to 
the  underlying  IGES  standard.  The  latest  release  of  the  IGES 
specification  is  version  4.0,  submitted  to  ANSI  for  ballot  as 
a  national  standard,  but  not  yet  approved.  A  version  5.0  is 
currently  being  developed  by  the  voluntary  IGES/PDES 
organization. 

The  latest  subset  being  developed  for  MIL-D-28000  is  the 
3D  piping  subset.  It  is  being  created  by  members  of  the  Navy 
Industry  Digital  Data  Exchange  Standards  Committee  (NIDDESC) 
and  the  IGES/PDES  Organization.  The  subset  will  be  included 
in  a  future  release  of  MIL-D-28000. 

2.2.4  PROBLEMS 

A  possible  concern  with  the  implementation  of  MIL-D-28000 
is  the  method  by  which  the  senders  of  a  MIL-D-28000  file  will 
produce  the  file.  The  preferred  method  would  be  for  the  CAD 
system's  IGES  translator  to  produce  the  MIL-D-28000  file.  But, 
what  may  happen  is  that  the  CAD  system  may  produce  the  IGES 
file  and  then  the  file  may  be  run  through  a  commercial 
flavorizer  to  produce  a  MIL-D-28000  compliant  file.  This 
method  must  be  performed  very  carefully  to  prevent  any  loss 
of  the  file's  underlying  structure. 

Even  if  the  application  subset  transfers  perfectly,  that 
doesn't  ensure  that  all  of  the  information  in  the  original  CAD 
model  will  be  translated.  For  example,  a  CAD  system  may 
recognize  objects  such  as  pipes  and  valves  in  its  internal 
data  base,  but  since  IGES  has  no  standard  way  to  represent 
objects  such  as  pipes  and  valves,  these  objects  may  be 
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transferred  as  a  grouping  of  points,  lines  and  curves  which 
represent  the  object.  The  concept  that  a  group  of  entities 
represent  an  object  is  not  necessarily  conveyed  by  the  subset 
to  the  receiving  CAD  system.  MIL-D-28000  displays  an  awareness 
of  that  problem  by  specifying  that  "It  is  the  intent  of  this 
specification  to  evolve  in  the  direction  of  application 
protocols  to  ensure  quality  data  exchanges".  The  application 
protocol  work  is  being  developed  within  the  IGES/PDES 
Organization  to  transfer  objects  instead  of  merely  a  wire 
frame  representation  of  lines,  arcs,  and  points  with  no 
intelligence  attached. 


2.2.5  EXTENT  AND  NATURE  OF  USER  AND  VENDOR  SUPPORT 

The  IGES  specification  has  much  support  from  the  CAD 
system  vendors.  Most  CAD  systems  have  some  type  of  IGES 
translator,  and  even  some  of  the  non-CAD  systems,  such  as 
Interleaf  (an  electronic  publications  system) ,  support  the 
IGES  specification.  The  support  for  MIL-D-28000  (i.e.,  the 
subsets)  is  not  as  widespread  as  the  support  for  the  full  IGES 
standard.  The  greatest  stated  support  of  the  subsets  comes 
from  the  commercial  flavoring  systems.  This  doesn't  mean  that 
the  native  CAD  systems  can't  support  MIL-D-28000.  They  can 
design  their  models  so  that  the  IGES  entities  output  by  the 
CAD  system's  IGES  translator  belong  to  the  MIL-D-28000  subset, 
and  manually  put  in  the  required  information  in  the  IGES  start 
section. 


2.2.6  STRUCTURE  OF  THE  STANDARDS  DEVELOPMENT 
ORGANIZATION (S) 

The  CALS  standards  are  being  developed  jointly  by  DoD, 
the  military,  federal  agencies  and  private  industry,  under  the 
direction  of  the  Department  of  Defense.  Comments  are  solicited 
through  comment/suggestion  forms  at  the  back  of  each  of  the 
standards.  These  are  sent  into  the  CALS  Policy  Office.  The 
comments  that  are  accepted  are  incorporated  into  an  amendment 
to  the  standard,  and  are  published  in  December/ January. 
Comments  on  the  standards  can  be  sent  to  the  Directory,  CALS 
Policy  Office,  OASD(P&L)WSIG  Pentagon,  Room  2B322,  Washington, 
DC  20301  using  the  form  at  the  end  of  MIL-D-28000  or  a  letter. 

The  IGES/PDES  Organization  is  developing  the  base 
standard,  the  Initial  Graphics  Exchange  Specification  (IGES) , 
under  the  direction  of  the  Project  Manager,  Dennette  Harrod 
of  Computer  Vision.  Changes  to  the  Specification  are  submitted 
as  a  Request  For  Change  (RFC)  which  are  balloted  by  mail  to 
all  the  members  of  the  IGES/PDES  organization.  Any  accepted 
changes  are  incorporated  in  the  next  release  of  the  IGES 
specification.  The  specification  is  then  sent  to  the  American 
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National  Standards  Institute  for  ballot  as  a  national 
standard.  Comments  on  the  specification  can  be  addressed  to: 
Gaylen  Rinaudot,  Coordinator,  IGES/PDES,  National  Institute 
of  Standards  and  Technology,  Building  220,  Room  A150, 
Gaithersburg,  MD  20899. 


2.2.7  TESTING  AND  VALIDATION 

The  CALS  Test  Network  (CTN)  was  established  to  perform 
end-to-end  testing  of  the  exchange  of  digital  product 
definition  data  using  MIL-D-1840A,  and  to  recommend  changes 
to  that  document.  One  of  the  initial  standards  to  be  tested 
will  be  MIL-D-28000,  Representation  for  the  Communication  of 
Product  Data,  IGES  Application  Subsets.  The  testing  is 
directed  by  the  Air  Force  Logistics  Command  and  performed  by 
Lawrence  Livermore  National  Laboratories,  the  military 
services  and  volunteer  companies. 

The  CTN  will  test  the  current  CALS  data  interchange 
standards,  but  will  not  try  to  specifically  test  whether  the 
software  systems  used  (e.g.,  translators)  conform  to  the  CALS 
standards.  The  purpose  of  the  network  is  to  "evaluate  the 
effectiveness  of  CALS  standards  for  data  interchange"  and 
"demonstrate  the  effectiveness  and  benefits  of  employing 
digital  data  exchange  rather  than  paper  copy".  The  tests  used 
will  be  end-to-end  tests,  under  actual  conditions  and 
structured  tests.  The  results  that  have  been  reviewed  and 
approved  by  the  CTN  will  be  available  on  the  CALS  bulletin 
board  for  public  view. 


2.2.8  REFERENCE  AND  IMPLEMENTATION  DOCUMENTS  AVAILABLE 

MIL-D-28000,  Digital  Representation  For  Communication  of 
Product  Data:  IGES  Application  Subsets 

MIL-HDBK-59  Department  of  Defense  Computer-Aided 
Acquisition  and  Logistic  Support  (CALS)  Program  Implementation 
Guide 

MIL-STD-1840A  Automated  Interchange  of  Technical 
Information 

(Copies  of  the  preceding  military  standards  may  be  ordered 
from:  Department  of  Defense  Single  Stock  Point,  Commanding 

Officer,  Naval  Publications  and  Forms  Center  (NPFC) ,  5801 

Tabor  Avenue,  Philadelphia,  PA  19120.) 
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CALS  Test  Network  MIL-D-28000  Class  II  Reference  Drawing 
Packet  Revision  C,  Lawrence  Livermore  National  Laboratory, 
Jill  Parrel,  January  27,  1989.  (The  document  contains  helpful 
information  for  carrying  out  tests  of  the  MIL-D-28000  class 
II  subset.) 

CALS  Bulletin  Board  Numbers:  (301)  921-9842 

(301)  948-7438 


The  latest  released  IGES  Specification  can  be  ordered  from  the 

National  Technical  Information  Service  (NTIS) : 

National  Technical  Information  Service  (NTIS) 

5285  Port  Royal  Road 
Springfield,  VA  22161 
Telephone:  (703)487-4650 
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2.3  MARKUP  REQUIREMENTS  AND  GENERIC  STYLE  SPECIFICATION  FOR 
ELECTRONIC  PRINTED  OUTPUT  AND  EXCHANGE  OF  TEXT 
(MIL-M-28001) 

2.3.1  PURPOSE 

MIL-M-28001  establishes  requirements  for  the  digital 
interchange  of  technical  publication  text  between  contractors 
and  the  government.  MIL-M-28001  is  the  DoD  implementation  of 
the  international  standard  ISO  8879  "Standard  Generalized 
Markup  Language  (SGML)".  Some  familiarity  with  SGML  is  needed 
to  understand  MIL-M-28001. 

The  SGML  standard  defines  a  method  and  a  "language"  for 
document  representation.  It  provides  a  formal  markup 
("document  tagging")  procedure  independent  of  system  and 
output  environments.  It  provides  a  coherent  and  unambiguous 
syntax  ("language")  for  describing  whatever  a  user  chooses  to 
identify  within  a  document  -  the  document's  "structure"  - 
regardless  of  the  type  of  document  or  the  nature  of  the 
document's  text.  The  definition  of  the  document  structure  in 
terms  of  "elements",  "entities",  and  other  components  is  a 
"Document  Type  Definition  (DTD)".  A  DTD  defines  the  structure 
of  a  specific  class  of  documents.  Paragraph  2.3.9  presents 
illustrative  examples. 

The  SGML  markup  of  a  document  consists  of  inserting  tags 
into  the  unformatted  text.  These  tags  identify  the  text's 
elements  (titles,  paragraphs,  tables,  footnotes,  etc.)  as 
defined  by  the  document's  DTD.  SGML  markup  may  be  done  either 
manually  or  by  an  automated  procedure.  The  "marked  up" 
document  should  be  checked  against  the  appropriate  DTD  to  be 
sure  that  its  markup  conforms  to  the  conditions  imposed  by 
that  DTD.  This  process  is  called  "parsing"  and  is  done  by 
special  computer  programs  called  "parsers". 

The  Department  of  Defense  developed  two  DTDs  for  Military 
Technical  Manuals  with  respect  to  MIL-M-38784B  (Technical 
Manuals:  General  Style  and  Format  Requirements) .  These  two 
DTDs  are  currently  provided  in  appendices  of  MIL-M-28001.  The 
first  DTD  is  for  technical  manuals  which  strictly  conform  to 
MIL-M-38784B .  The  second  DTD  is  for  technical  manuals  which 
do  not  conform  as  strictly  to  MIL-M-38784B.  The 

non-conforming  DTD  is  necessary  since  often  an  existing  manual 
cannot  be  made  to  conform  to  the  DTD  for  MIL-M-38784 
conforming  manuals  or  because  the  manual  was  written  to 
multiple  specifications.  When  other  applications  of  automating 
technical  publication  are  identified,  and  if  the 
MIL-M-28001  DTDs  are  inadequate  for  these  applications,  new 
DTDs  will  be  developed  and  added  to  MIL-M-28001.  However,  any 
new  DTD  must  use  the  standard  tag  set  defined  in  MIL-M-28001, 
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and  must  conform  (as  much  as  possible)  to  the  structure  and 
intent  of  the  existing  MIL-M-28001  DTDs. 


2.3.2  APPLICATIONS 

The  development  of  the  two  DTDs  currently  in  MIL-M-28001 
was  a  joint  effort  of  the  Navy,  Army,  Air  Force,  and  Aerospace 
Industry.  Each  representative  to  this  joint  effort  brought 
an  existing  application  or  study  of  technical  manual 
automation.  The  Air  Force  ATOS  (Automated  Technical  Order 
System)  project  was  deemed  to  be  the  only  "true"  DoD  SGML 
application.  Accordingly  it  was  used  as  a  guideline  and  was 
modified  with  respect  to  Air  Force,  Navy,  Army,  ard  Aerospace 
Industry  technical  manual  requirements.  The  ATOS  project  is 
now  known  as  "AFTOMS"  (Air  Force  Technical  Order  Management 
System) .  The  AFTOMS  project  is  now  revising  their  original  DTD 
to  conform  to  MIL-M-28001. 

The  Navy  has  been  investigating  their  current  library  of 
NAVSEA  Ships'  Technical  Manuals  (NSTMs)  with  respect  to 
MIL-M-28001.  By  creating  an  SGML  data  base  of  these  technical 
manuals,  it  will  be  possible  to  interchange  data  and 
print-on-demand  on  all  publishing  systems  conforming  to 
MIL-M-28001. 

Currently,  MIL-M-28001  is  concerned  with  the  digital 
interchange  of  paper-based  manuals.  However,  there  are 
efforts  underway  to  define  digital  interchange  of  "pageless" 
technical  publications.  The  Air  Force  Human  Resource 
Laboratory  has  a  pilot  project  which  uses  SGML  to  define  the 
interchange  of  maintenance  data  to  be  maintained  in  a 
relational  data  base  from  which  multiple  "views"  of  the  same 
data  can  be  extracted.  This  data  base  is  constructed  so  as  to 
facilitate  implementation  of  the  "interactive-type" 
(hypertext)  maintenance  system. 


2.3.3  PLANNED  EXTENSIONS 

In  order  to  format  an  SGML  marked-up  document, 
"associated  formatting  information"  must  be  provided.  This 
"associated  formatting  information"  defines  formatting 
characteristics  such  as  a  page  model,  font  and  family 
characteristics,  point  size,  indenting,  etc.  In  addition, 
these  formatting  characteristics  can  be  changed  by  certain 
SGML  tags.  For  example,  a  "paragraph"  tag  may  trigger  a 
change  in  the  line  leading  (spacing)  or  a  "chapter  head"  tag 
may  trigger  text  to  be  "bold"  or  "centered".  An  "MIL-M-28001 
Output  Specification  Group"  was  formed  to  develop  a  standard 
language  for  the  associated  formatting  information  of 
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SGML-tagged  files.  SGML  was  chosen  as  the  language  of  the 
Output  Specification  (OS) . 

For  each  DTD,  a  "Formatted  Output  Specification  Instance" 
(FOSI)  will  be  developed  (paragraph  2.3.9  presents 
illustrative  examples) .  A  FOSI  will  follow  rules  in  the 
Output  Specification  and  will  specify  parameter  values  for  the 
format  requirements  of  the  document.  Accordingly  a  FOSI  for 
a  particular  DTD  will  describe  all  default  formatting 
characteristics  necessary  to  compose  and  publish  a  document. 
Authors  will  have  the  capability  to  override  a  FOSI  if  a 
format  other  than  the  default  is  needed  for  a  particular 
document.  Since  FOSIs  are  written  with  respect  to  the 
standard  OS,  vendors  will  be  able  to  develop  software  that  can 
"read"  FOSIs  and  interface  with  the  publishing  software. 

In  addition  to  the  OS  and  FOSI  extensions,  there  is  at 
present  a  draft  amendment  to  MIL-M-28001  which  contains  the 
notion  of  a  "declaration  subset".  These  declaration  subsets 
specify  slight  changes  to  the  present  DTDs.  The 
implementation  of  the  changes  in  a  declaration  subset  results 
in  a  complete  DTD  for  the  corresponding  military 
specification:  MIL-M-21742,  MIL-M-26788,  MIL-M-38812, 
MIL-M— 63004,  MIL-M-63036,  MIL-M-63038,  MIL-M-63041, 
MIL-M-6675,  MIL-M-83943,  MIL-M-9994,  WS-10759-1,  WS-10759-2, 
or  WS— 1759— 3 .  This  proposal  for  "declaration  subsets"  is 
expected  to  be  accepted  since  permitting  slight  modification 
of  an  existing  DTD  allows  tighter  control  over  the  number  of 
distinct  DTDs.  While  DoD  wishes  MIL-M-28001  to  be  implemented 
in  a  wide  variety  of  applications,  DoD  is  quite  concerned  with 
the  uncontrolled  proliferation  of  DTDs. 


2.3.4  PROBLEMS  AND  LIMITATIONS  WITH  CURRENT 
SPECIFICATION 

The  latest  official  draft  of  MIL-M-28001  was  published 
26  February  1988.  Industry  and  government  agencies  sent 
comments  to  the  Electronic  Publishing  Committee  (a  CALS 
Industry  Standard  working  sub-group) .  A  draft  report 
concerning  these  comments  was  prepared  but  has  not  yet  been 
officially  issued  and  published.  As  a  result  the  solutions 
proposed  by  the  committee  to  problems  raised  in  the  comments 
have  not  been  seen  and  reviewed.  The  issues  raised  by  industry 
and  government  agencies  involve: 

-  method  of  tagging  tables 

-  linkage  of  SGML  tagged-text  with  Raster  graphics 

-  receiving  partial  "change  package"  documents 
from  contractors 
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2.3.5  EXTENT  AND  NATURE  OF  USER  AND  VENDOR  SUPPORT 


The  vendor  community  is  aware  of  the  evolving  nature  of 
MIL-M-28001.  Some  are  waiting  until  the  standard  is 
finalized,  while  others  are  beginning  to  implement 
MIL-M-28001.  A  large  vendor  community  is  represented  on  the 
Electronic  Publishing  Committee.  In  a  CALS  environment, 
vendors  supporting  MIL-M-28001  must  not  "hard-code"  their 
systems  to  process  only  a  single  DTD/FOSI.  Most  certainly 
there  will  be  more  SGML  applications  (DTDs)  in  the  future  and 
vendors  whose  systems  can  handle  any  given  DTD/FOSI  will  have 
the  advantages. 

Currently  there  are  many  SGML  software  products  on  the 
market.  These  are: 

SGML  parsers  which  conform  to  ISO  8879.  Parsers  check 
DTDs  for  completeness  and  consistency  to  all  ISO  8879 
rules.  A  parser  then  parses  an  "instance  of  the  DTD": 
a  document  marked  up  with  tags  defined  in  the  DTD.  The 
parser  reports  on  errors  found  in  the  parsing  process. 
Many  general  purpose  SGML  software  packages  come  with  a 
"built-in"parser . 


SGML  Author/Editors  which  "understand"  the  DTD  as  it  is 
given.  It  will  guide  an  author  through  the  creation  of 
a  document,  not  requiring  the  author  to  type  in  the  SGML 
tags.  The  keyed  in  text  is  automatically  formatted  and 
displayed  on  the  screen.  The  document  can  be  output  in 
SGML  format,  or  as  a  formatted  page  description  file. 
In  other  words,  as  the  author  indicates  the  start  of  a 
new  paragraph,  the  editor  automatically  supplies  the 
appropriate  SGML  tag. 

Software  which  automatically  tags  an  ASCII  file  based  on 
format-driven  triggers.  Most  of  the  "structure"  type  tags 
(for  paragraphs,  lists,  etc.)  can  be  automatically 
generated  without  any  trouble.  However,  unless  the 
software  is  very  sophisticated,  the  "content"  type  tags 
(for  cross  references,  equipment  numbers,  etc.)  cannot 
be  automatically  generated.  Content  type  tags  are  very 
important  in  data  base  applications. 

In  addition,  this  type  of  software  can  be  used  in 
conjunction  with  media  converters  which  translate  formatted 
"system-dependent"  files  (i.e.,  "WordPerfect")  into  SGML 
files. 
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2.3.6  STRUCTURE  OF  THE  DEVELOPMENT  ORGANIZATION 


The  MIL-M-28001  development  organization  consists  of  two 
subgroups  of  the  "CALS  Industry  Standards  Working  Group".  One 
is  the  MIL-M-28001  working  group,  the  "Electronic  Publishing 
Committee",  which  is  responsible  for  reviewing  industry  and 
Government  comments  with  respect  to  the  standard  and  proposes 
changes  when  necessary. 

Another  subgroup,  the  "MIL-M-28001  Output  Specification 
Committee",  developed  the  Output  Specification.  A  sub-group 
of  this  committee  is  responsible  for  developing  the  FOSIs  for 
the  two  DTDs  currently  in  MIL-M-28001. 


2.3.7  TESTING  AND  VALIDATION 

Much  "private"  testing  of  MIL-M-28001  took  place  as  part 
of  the  general  review  of  the  26  February  1988  draft.  The  CALS 
Test  Network  (CTN)  provides  information  on  developing  test 
material,  identifies  appropriate  parties  to  share  test 
material  with,  and  distributes  instructions  on  performing 
tests.  Test  results  with  regard  to  proposed  changes  to 
MIL-M-28001  will  be  submitted  to  the  Electronic  Publishing 
Committee.  The  Electronic  Publishing  Committee 
enthusiastically  encourages  extensive  testing  of  the 
MIL-M-28001  DTDs. 


2.3.8  REFERENCE  AND  IMPLEMENTATION  DOCUMENTS 

The  primary  SGML  reference  document  is  the  International 
Standard,  ISO  8879  "Information  Processing  -  Text  and  Office 
Systems  -  Standard  Generalized  Markup  Language  (SGML)".  This 
is  the  authoritative  source  for  SGML  and  the  most  general 
description  of  SGML.  All  SGML  implementations  are  based  on  the 
"language"  defined  therein. 

MIL-M-28001  describes  the  Navy's  use  of  SGML  with  respect 
to  Navy  Technical  Manuals.  It  contains  much  useful 
information,  in  addition  to  providing  the  DTDs  and  master  list 
of  elements. 

The  "<TAG>"  newsletter  is  published  by  SGML  Associates, 
Inc. ,  and  the  Graphic  Communications  Association,  1730  N.  Lynn 
St.  Suite  604,  Arlington,  VA  22209.  "<TAG>"  is  a  technical 
journal  of  the  SGML  community. 
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2.3.9  ILLUSTRATIVE  EXAMPLES 


For  illustrative  purposes,  this  section  presents  a 
simplified  example  of  a  DTD,  an  SGML  ’'marked  up”  document,  and 
a  FOSI .  In  the  examples,  it  is  assumed  that  a  "technical 
manual"  document  type  is  required  to  have  a  title  and  must 
contain  at  least  one  chapter  and  each  chapter  must  have  a 
title  and  contain  at  least  one  paragraph.  These  requirements 
can  be  stated  as  a  simple  DTD  in  SGML  notation  as: 

< 1 DOCTYPE  TECHMANL  [ 

<! ELEMENT  techmanl  -  -  (title,  intro,  chap+)> 

<! ATTLIST  techmanl  label  NMTOKEN  #IMPLIED  > 

<! ELEMENT  title  -  o  (# PCDATA)  > 

< I  ELEMENT  intro  -  o  (parag+)  > 

<! ELEMENT  chap  -  o  (title,  parag+)  > 

<! ELEMENT  chap  label  NMTOKEN  #IMPLIED  > 

<! ELEMENT  parag  -  o  (# PCDATA)  > 

]> 

This  constitutes  a  simple  DTD.  The  first  "<! DOCTYPE" 
statement  indicates  that  a  DTD  is  about  to  be  defined  and  the 
final  " ]>"  notation  terminates  that  definition. 

The  SGML  markup  of  a  simple  technical  manual  in 
accordance  with  the  above  DTD  may  be  represented  as: 

ctechmanl  label="437"> 

<title>SIMPLE  TECHNICAL  MANUAL 
<intro> 

<parag>This  is  the  required  first  paragraph  of  the 
introduction . 

<parag>This  is  the  optional  second  paragraph  of  the 
introduction. 

</ intro 

<chap  label="l"> 

<parag> 

This  is  the  required  first  paragraph  of  the 

required  first  chapter 

<parag> 

This  is  the  optional  second  paragraph  of  the 
required  first  chapter. 

<chap  label="2"> 

<parag> 

This  is  the  required  first  paragraph  of  the 
optional  second  chapter. 

</techmanl> 

The  "label"  attribute  modifies  the  "techmanl"  tag  by 
specifying  that  it  is  number  437.  The  "label"  attribute  for 
the  "chap"  tags  specifies  the  two  chapter  numbers.  The  "end" 
tags  referred  to  above  are  those  tags  beginning  with  "</". 


Note  that  the  DTD  did  not  require  the  "</intro>H  ("intro" 
end  tag)  but  it  was  not  incorrect  to  include  it. 


In  order  for  a  publishing  system  to  format  a  marked-up 
technical  manual,  a  FOSI  must  be  defined  for  it.  The  FOSI  is 
also  written  in  SGML  notation  so  it  will  be  processable  by 
computer  software.  An  example  of  a  simplified  FOSI  is: 

<eic  lgi="techmanl">  <charlist>  <font  size="10pt", 
weight="medium">  <eic  gi="title"xcharlistxfont 
weight="bold"> 

<eic  gi=" intro" >  <charlist>  <textbrk  startpg="l"> 
<puttext= "INTRODUCTIONS 

<eic  gi="chap">  <charlist>  ctextbrk  startpg="l"> 
<puttext=" CHAPTER" > 

<eic  gi="parag"  context="chap">  <charlist>  <indent 
lef t indent=" lOpt " > 

The  FOSI  looks  somewhat  similar  to  the  marked-up 
technical  manual  above,  without  any  authored  text.  That  is 
because,  just  as  the  marked-up  technical  manual  follows  the 
rules  of  its  DTD  (is  an  "instance"  of  its  DTD) ,  this  FOSI  is 
an  instance  of  the  OS  (which  is  written  as  a  DTD  and  is 
published  in  MIL-M-28001) . 

Each  line  in  the  FOSI  example  which  starts  with  <eic 
gi=" ...">  contains  the  formatting  characteristics  for  an 
element  of  the  DTD.  "eic"  denotes  "element  in  context",  "gi" 
denotes  generic  identifier  and  relates  to  the  elements  of  the 
DTD.  "context"  refers  to  the  context  in  which  the  generic 
identifier  is  defined.  Thus,  the  last  line  identifies 
formatting  characteristics  for  paragraphs  in  a  chapter  (as 
opposed  to  paragraphs  in  the  introduction) . 

According  to  the  FOSI,  the  technical  manual  is  to  be 
formatted  with  font  size  of  10  points  and  medium  width.  The 
title  should  be  bold.  The  introduction  is  to  start  a  new 
page,  and  the  word  "INTRODUCTION"  be  automatically  generated. 
The  chapter  should  start  a  new  page,  and  the  word  "CHAPTER" 
should  be  automatically  generated.  Paragraphs  within  the 
chapter  should  have  a  left  indent  of  10  points. 
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2.4  RASTER  GRAPHICS  REPRESENTATION  IN  BINARY  FORMAT 
(MIL-R-28002) 

2.4.1  PURPOSE  AND  APPLICATIONS 

The  MIL-R-28002  specification  establishes  requirements 
regarding  the  storage  and  transmission  format  of  raster 
graphics  data  and  tiling  conventions  for  document  pages  and 
large  format  engineering  drawings  as  raster  images.  Issued 
in  December  1988,  this  milspec  defines  raster  graphics  data 
requirements  for  both  the  tiled  and  untiled  modes.  This 
milspec  is  dependent  on  two  other  government  documents: 
MIL-STD-1840A  "Automated  Interchange  of  Technical  Information" 
and  NISTIR  88-4017  "Standards  for  the  Interchange  of  Large 
Format  Tiled  Raster  Documents." 

Raster  graphics  involves  the  digital  processing,  storage, 
exchange  and  reproduction  of  images.  This  technology  makes 
possible  the  binary  representation  of  a  two-dimensional  image 
as  an  array  of  picture  elements,  also  known  as  pels.  Each  pel 
of  the  array  contains  information  concerning  the  color  and 
brightness  of  that  portion  of  the  image.  The  quality  of  the 
image  depends  directly  on  the  density  of  pels  within  the 
array,  also  known  as  resolution  density  or  pel  transmission 
density.  A  high  resolution  density  provides  a  high  quality 
image,  but  entails  the  added  drawback  of  greater  and  more 
costly  storage.  Data  compression,  in  which  an  encoding  scheme 
is  used  to  represent  redundant  bits  of  information,  can 
alleviate  this  storage  problem  to  some  extent.  MIL-R-28002 
restricts  such  compression  to  Group  4  encoding  as  defined  in 
CCITT  Recommendation  T.6  (FIPS  PUB  150)  in  order  to  conform 
with  developing  industry  standards.  A  set  of  graphics 
attributes  specifying  the  details  necessary  for  processing  and 
reproducing  the  image  is  contained  in  a  header  record  at  the 
beginning  of  a  raster  file.  These  attributes  include  the  size 
of  the  original  image,  the  scanning  resolution,  the  image 
orientation  (whether  it  be  portrait  or  landscape) ,  the 
starting  position  on  the  page,  and  the  spacing  between  the 
pels  and  also  between  the  lines  containing  the  pels.  These 
principles  and  attributes  are  used  in  reproducing  the  image 
and  apply  to  both  of  the  raster  graphics  formats.  Type  I 
format  applies  to  untiled  raster  graphics  while  the  Type  II 
format  is  the  Type  I  format  enhanced  with  tiling. 

With  Type  II  (tiled)  raster  graphics,  an  image  is 
subdivided  into  non-overlapping  regions  known  as  tiles,  and 
each  tile  is  treated  as  a  separate  pel  array.  This  method  is 
especially  useful  for  mechanical  drawings  in  which  there  are 
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large  open  areas  of  space.  Figure  9  shows  an  image  overlayed 
with  a  grid  coordinate  system  to  produce  the  smaller  tile 


Figure  9.  Tiled  Raster  Graphics  Example 

subdivisions.  Within  a  single  image,  tiles  are  equal  in  size 
and  their  dimensions,  specified  in  terms  of  pels,  have 
limitations.  Tiles  can  be  compressed  and  manipulated  to 
obtain  an  optimal  raster  graphics  file.  However,  it  is 
possible  that  compression  can  negatively  compress  or  enlarge 
a  data  set,  especially  in  busy  areas  of  an  image.  Thus, 
compression  must  be  employed  with  care.  In  such  situations, 
an  optimal  raster  graphics  file  can  be  obtained  using  a 
mixture  of  compressed  and  uncompressed  tiles.  MIL-R-28002 
recommends  that  a  tile  index  be  used  to  allow  for  direct 
access  of  individual  tiles.  Unless  a  contract  provides 
otherwise, the  milspec  requires  Government  vendors  to  deliver 
Type  I  (untiled)  format  raster  graphics  data. 

A  second  group  of  attributes  is  required  for  Type  II 
raster  graphics.  This  information  includes  the  size  of  each 
tile,  the  number  of  tiles  in  the  array  or  image,  the  method 
of  tile  ordering,  and  the  method  of  tile  coding.  This 
information  is  stored  in  the  header  record  of  an  image  file 
during  the  scanning  procedure  and  is  essential  for  reproducing 
an  image. 
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2.4.2  LIMITATIONS 


Although  MIL-R-28002  provides  specifications  to  unify  the 
format  of  raster  graphics  data,  there  are  some  potential 
problems  and  limitations.  One  crucial  issue  is  resolution. 
The  specification  permits  resolution  densities  of  200,  240, 
300,  400,  600  and  1200  pels  per  inch  with  a  default  value  of 
200  pels  per  inch.  Although  the  milspec  provides  typical 
values  for  use  in  both  document  text  and  large  size  foldout 
drawings,  it  fails  to  specify  a  required  value  for  use  in 
either  text  or  drawings.  Most  resolutions  in  that  range 
result  in  excessive  storage  and  processing  requirements, 
compatibility  problems,  and  production  delays.  For 
engineering  drawings,  many  industry  experts  feel  that  a 
specified  resolution  of  200  pels  per  inch  would  provide 
adequate  quality  as  well  as  cost  effectiveness  with  respect 
to  storage  allocation,  scanning  equipment,  and  production 
time.  The  default  value  of  200  pels  per  inch  is  considered 
too  low  for  publishing  industry  standards.  A  separate  default 
value  of  300  pels  per  inch  for  text  documents  may  need  to  be 
specified  to  avoid  problems  with  both  compatibility  and 
manuals  of  less  than  letter  quality.  However,  at  this  time 
there  is  no  way  to  determine  from  the  header  record 
information  whether  the  raster  file  data  is  for  a  document  or 
a  drawing. 

MIL-R-28002  does  not  specify  the  tiling  conventions  for 
technical  manual  foldouts  differing  in  size  from  the  standard 
engineering  sizes  A-K.  This  could  lead  to  interchange  problems 
and  production  delays. 

With  tiled  raster  graphics,  the  standard  allows  tiles  of 
a  graphic  image  to  be  stored  as  either  a  series  of  octet  bit 
strings  known  as  bitmap  encoded  data,  compressed  data,  or  a 
combination  of  the  two.  This  procedure  is  optimal  for  data 
storage,  but  it  requires  alternating  methods  for  the 
decompression  and  straight  usage  of  data.  Thus,  both 
processing  time  and  cost  could  increase. 

Within  the  Type  II  tiled  architecture,  the  "tiled  context 
portion"  attribute  is  permitted  to  have  the  value  of 
"Maybe-Null-Tiles" .  Containing  no  data,  null  tiles  are  used 
for  image  compression  and  are  particularly  important  to  the 
processing  of  foldout  drawings.  However,  processing  null 
tiles  can  cause  delays.  Also,  they  are  not  necessary  for  text 
documents.  Restrictions  concerning  the  use  of  null  tiles  may 
be  needed. 

The  MIL-R-28002  standard  states  that  the  typical  image 
orientation  for  a  page  can  be  specified,  in  degrees,  using  the 
pel  path  and  line  progression  attributes.  This  determines 
whether  the  layout  will  have  a  portrait  or  a  landscape 
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orientation.  If  a  text  document  is  given  a  landscape 
orientation  by  mistake,  the  information  will  be  printed 
incorrectly,  which  could  be  costly  in  terms  of  time  and 
money.  By  forcing  a  portrait  orientation  for  text  pages  using 
these  or  other  attributes  in  the  header  record  printing 
orientation  errors  could  be  avoided. 


2.4.3  PLANNED  EXTENSIONS 

Some  changes  will  probably  be  made  to  the  milspec  in  the 
future,  most  likely  in  the  areas  of  bit  mapping  and  bit 
ordering  in  the  Type  II  architecture.  It  is  possible  that  the 
OSD-CALS  Office  will  add  a  provision  for  a  tiling  convention 
in  regard  to  technical  manual  foldouts. 


2.4.4  DEVELOPMENT  ORGANIZATION 

This  milspec  was  prepared  by  the  OSD-CALS  Office  with 
assistance  from  a  Government/Industry  Tiling  Task  Group  (TTG)  . 


2.4.5  TESTING  AND  VALIDATION 

A  system  for  use  in  testing  and  validation  is  currently 
being  developed  jointly  by  the  OSD-CALS  Office  and  NIST 
(National  Institute  of  Standards  and  Technology,  formerly  the 
National  Bureau  of  Standards) .  This  system  is  scheduled  to 
be  available  in  September  1989. 

Presently,  the  Navy  is  using  both  tiled  and  untiled 
formats  to  test  the  conversion  of  documents  into  raster 
graphics  files.  EDMICS  (Engineering  Data  Management 
Information  Control  System) ,  which  has  been  a  joint  effort  of 
the  Navy  and  Defense  Logistics  Agency,  is  in  full  conformance 
with  MIL-R-28002.  This  management  system  for  engineering 
drawings  uses  tiles  that  are  512  x  512  pels  in  size.  Although 
the  standards  were  prepared  for  its  use  in  the  future,  tiled 
raster  graphics  format  is  currently  being  used  for  a 
repository  of  aperture  cards  at  a  NAVSEA  facility  in  San 
Diego,  CA.  SPAWAR  is  using  raster  graphics  with  drawings  for 
demonstration  purposes.  Both  NAVAIR  and  NAVSEA  are  using  the 
untiled  format  for  technical  manuals  and  engineering  drawings. 
The  Army  and  Air  Force  are  also  using  the  untiled  format  for 
testing  their  repositories  of  drawings. 


2.4.6  IMPLEMENTATION  AND  REFERENCE  DOCUMENTS 

To  assist  with  the  implementation  of  MIL-R-28002,  the 
National  Institute  of  Standards  and  Technology  has  released 
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NISTIR  88-4017  "Standards  for  the  Interchange  of  Large  Format 
Tiled  Raster  Documents."  This  document  describes  the  basic 
concepts  of  raster  graphics,  the  architecture  structure  of  the 
tiled  or  Type  II  format,  and  the  applications  of  tiling. 
Other  supporting  documents  of  MIL-R-28002  include  the 
following: 


Specifications 

DOD-D-IOOO  Drawings,  Engineering  and 

Associated  Lists 


MIL-M-9868 


Requirements  for  Microfilming 
of  Engineering  Documents,  35  mm 


Standards 

FIPS  PUB  150 


Telecommunications:  Facsimile 
Coding  Schemes  and  Coding 
Control  Functions  for  Group  4 
Facsimile  Apparatus 


DOD-STD-100  Engineering  Drawing  Practices 

MIL-STD-1840A  Automated  Interchange  of 

Technical  Information 


Parts  1,  2,  4,  5,  and  7  of  the  international  standard  ISO 
8613,  which  address  the  Office  Document  Architecture  (ODA)  and 
interchange  format,  form  a  significant  portion  of  MIL-R-28002. 
Other  standards  that  support  MIL-R-28002  are  ANSI  Y14.1,  ISO 
8824,  and  ISO  8825. 


46 


2.5  DIGITAL  REPRESENTATION  FOR  COMMUNICATION  OF  ILLUSTRATION 
DATA:  CGM  APPLICATION  PROFILE  (MIL-D-28003 ) 

2.5.1  PURPOSE 

MIL-D-28003  establishes  requirements  for  the  digital 
interchange  of  pictorial  and  illustration  data  which  is 
delivered  in  the  Computer  Graphics  Metafile  (CGM)  format. 
While  IGES  has  its  principal  use  within  computer-aided  design, 
CGM  will  be  used  primarily  in  authoring  and  graphic  art  work 
stations  for  technical  manual  illustrations.  MIL-D-28003  is 
the  DoD  implementation  of  FIPS  PUB  128  -  Computer  Graphics 
Metafile  which  adapts  ANSI  X3.122  as  a  Federal  Information 
Processing  Standard  Publication  (FIPS  PUB) .  Some  familiarity 
with  CGM  is  needed  to  understand  MIL-D-28003. 

The  purpose  of  the  Computer  Graphics  Metafile  (CGM) 
standard  is  to  provide  a  flexible  and  standard  file  format 
for  the  transfer  and  archival  of  graphical  information  in  a 
device  independent  manner.  A  graphical  metafile  (a  device 
independent  description  of  one  or  more  graphic  images)  is  a 
mechanism  for  the  capture,  storage,  and  transport  of  graphical 
information.  CGM  is  a  static  picture-capture  metafile.  The 
standard  only  covers  information  necessary  to  recreate  what 
is  seen  on  the  "screen".  It  does  not  contain  the  underlying 
information  needed  to  consider  the  relationships  of  objects 
on  the  screen. 


2.5.2  SCOPE  -  CGM  Standard 

CGM  is  described  in  ANSI  X3. 122-1986  "Computer  Graphics  - 
Metafile  for  the  Transfer  of  Picture  Description  Information". 
The  document  contains  four  parts. 

Part  1,  the  Functional  Specification,  identifies  all 
standardized  elements,  describes  their  parameterizations  and 
defines  their  meanings.  Parts  two  through  four,  Character  2 
Encoding,  Binary  Encoding  and  Clear  Text  Encoding  describe 
three  data  encoding  schemes  for  implementing  the  functionality 
described  in  Part  1. 

Part  2,  Character  Encoding,  provides  an  encoding  using 
standard  ASCII  printable  characters.  The  encoding  is  compact 
and  is  well  suited  to  transmission  via  standard  character 
oriented  communications  mediums.  This  encoding  works  well  on 
character  oriented  network  systems.  It  is  used  in  Europe  but 
rarely  used  in  the  U.S. 

Part  3,  Binary  Encoding,  describes  an  encoding  which 
could  be  used  when  speed  of  generation  and  translation  are 
very  important.  The  encoding  data  formats  were  chosen  either 
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for  their  similarity  to  computer  data  formats  or  were  designed 
for  speed  of  decoding  and  processing.  This  form  of  encoding 
is  the  most  common  form  used  in  the  U.S.  (and  the  only 
encoding  supported  by  MIL-D-28003  at  this  time) . 

Part  4,  Clear  Text  Encoding,  defines  an  encoding  scheme 
which  is  human  readable.  Elements  and  parameters  are  specified 
in  terms  that  are  easily  understandable  to  a  person  reading 
the  metafile  data.  It  is  transmittable  over  character  oriented 
communications  but  is  slow  to  generate  and  is  not  very 
compact . 

The  three  data  encoding  schemes  are  equivalent  in  the 
sense  that  any  CGM  in  one  encoding  scheme  may  be  translated 
to  either  of  the  other  encoding  schemes  without  losing  or 
changing  any  of  the  picture  information. 

One  or  more  pictures  may  be  stored  in  a  metafile  and  the 
structure  of  the  elements  is  such  that  the  pictures  can  be 
accessed  sequentially  or  randomly.  That  is,  a  picture  is  an 
independent  entity  and  does  not  rely  on  information  in  any  of 
the  other  pictures  in  the  metafile. 

The  CGM  standard  is  designed  primarily  to  represent 
vector  graphics.  It's  implementation  is  based  on  the  Graphical 
Kernel  System  (GKS)  vector  standard  and  uses  standard  vector 
entities  such  as  point,  line,  arc,  circle,  polygon,  etc.  The 
standard  contains  a  capability  for  bit-map  like  representation 
using  a  graphical  primitive  called  cell  array.  The  cell  array 
is  a  two-dimensional  array  of  color  values  which  covers  a 
rectangle  or  parallelogram.  The  standard  contains  a  set  of 
features  to  describe  text  fonts  for  use  in  pictures  requiring 
type  face  definitions  and  character  spacing  parameters  for 
proportional  fonts. 


2.5.3  SCOPE  -  MIL-D-28003 

CGM  is  a  government  accepted  standard  as  represented  by 
its  Federal  Information  Processing  Standard,  FIPS  PUB  128. 
FIPS  PUB  128  is  a  document  which  essentially  states  that  ANSI 
X3. 122-1986  is  the  accepted  government  standard.  Military 
Specification  MIL-D-28003  "Digital  Representation  For 
Communication  of  Illustration  Data:  CGM  Application  Profile" 
(CGM  AP)  is  a  DoD  specific  document  which  establishes 
requirements  for  pictorial  and  illustrative  data  which  is 
delivered  in  CGM  format. 

The  CGM  AP  was  created  to  define  a  set  of  specifications 
appropriate  to  a  specific  application,  namely  the  interchange 
of  illustration  data  in  digital  format  for  use  in  technical 
illustrations  and  publications.  The  Application  Protocol  (AP) 
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clears  up  some  of  the  ambiguities  in  the  CGM  specification 
that  would  have  made  it  difficult  to  unambiguously  describe 
a  picture  using  a  CGM.  MIL-D-28003  specifies  complete 
semantics  for  a  CGM  and  describes  the  required  behavior  of 
CGM  generators  and  CGM  interpreters. 

MIL-D-28003  defines  the  conforming  basic  metafile, 
conforming  basic  generator  and  the  conforming  basic 
interpreter.  A  conforming  basic  metafile  is  a  CGM  which 
contains  only  elements  or  parameters  that  are  in  the  basic  set 
as  defined  in  the  Application  Profile.  A  conforming  basic 
generator  is  a  CGM  generator  which  generates  a  conforming 
basic  metafile,  and  a  conforming  basic  interpreter  is  a  CGM 
interpreter  which  can  correctly  interpret  a  conforming  basic 
metafile.  The  AP  also  states  some  corrections  for  errors  in 
the  ANSI  specification,  provides  some  Quality  Assurance 
provisions  and  states  that  the  binary  encoding  is  the  only 
encoding  supported  at  this  time. 


2.5.4  STATUS  of  CGM  Standard  /  TESTING 

CGM  has  become  widely  accepted  in  industry  since  it 
became  an  American  National  Standards  Institute  (ANSI) 
standard.  It  has  an  advantage  over  IGES  as  a  vector  standard 
in  that  it  is  an  "after-the-fact”  implementation  and  does  not 
contain  information  for  complex  content  modification,  which 
may  make  it  easier  for  a  vendor  to  implement.  CGM  is  an 
international  standard,  as  described  in  the  ISO  document  ISO 
8632-1986.  CGM  is  becoming  widely  available  for  authoring 
and  graphic  arts  workstations. 

There  are  currently  no  'certified'  interpreters  or 
generators  since,  to  date,  there  are  no  'certified' 
conformance  tests  to  determine  if  an  interpreter  or  generator 
conforms  to  the  standard.  The  ANSI  CGM  standard  does  not 
specify  standard  metafile  interpreters  or  metafile  generators. 
Part  one  of  the  ANSI  document  X3. 122-1986  (annex  D)  provides 
some  guidelines  for  implementations  of  interpreters  but  this 
section  is  not  part  of  the  standard.  There  are  several  groups, 
including  the  National  Institute  of  Standards  and  Technology 
(NIST) ,  which  are  working  on  developing  conformance  tests  for 
CGM  interpreters  and  generators. 


2.5.5  DEVELOPMENT  ORGANIZATION  /  EXTENSIONS 

There  are  three  major  ways  in  which  the  ANSI  standard  can 
be  modified.  It  is  an  ANSI  practice  that  every  five  years  a 
standard  goes  through  a  re-evaluation  period  to  determine  if 
any  changes  are  necessary. 


A  second  way  to  modify  the  standard  is  through  addendums. 
Addendums  currently  being  worked  on  address  adding 
segmentation  and  more  primitives  to  the  standard,  as  well  as 
including  additional  drawing  and  text  capabilities.  An 
addendum  to  add  three  dimensional  capabilities  to  CGM  is  being 
considered. 

The  third  way  to  modify  the  standard  is  by  getting  the 
modification  or  addition  registered  with  ANSI.  The  process  of 
registration  is  a  standard  way  of  taking  care  of  non-standard 
items.  A  registered  item  is  not  a  part  of  the  actual  standard 
but  implementers  of  the  standard  must  abide  by  registered 
items.  A  registered  item  does  not  have  to  become  part  of  a 
standard  but  they  generally  do. 


2.5.6  CONCLUSION 

MIL-D-28003  defines  the  use  of  the  CGM  for  two 
dimensional  vector  picture  descriptions  or  illustrations  in 
technical  manuals.  CGM  is  becoming  widely  available  for 
authoring  and  graphic  arts  workstations,  whereas  IGES  has  its 
principal  use  within  computer  aided  design.  CGM  may  be  a 
good  candidate  for  engineering  drawings  which  do  not  need  to 
be  updated.  Also,  the  CGM  cell-array  bit-map  feature  may  be 
a  good  alternative  to  MIL-R-28002  CCITT  Group  4  compression 
for  smaller  bit-map  illustrations  such  as  might  be  used  in  a 
frame-based  presentation  system.  Ongoing  CGM  extensions 
address  factors  needed  for  high  quality  presentation  graphics 
and  are  probably  not  needed  for  technical  illustrations  such 
as  being  used  in  the  CALS  environment.  Testing  and  validation 
are  still  relatively  new  but  with  increasing  interest  in 
industry  these  functions  should  progress  well  over  the  next 
few  years. 


2.5.7  REFERENCES 

FIPS  PUB  128,  "Computer  Graphics  Metafile" 

ANSI  X3. 122-1986,  "Computer  Graphics  -  metafile  for  the 
storage  and  transfer  of  picture  description  information" 

MIL-D-28003,  "Digital  Representation  for  Communication 
of  Illustration  Data:  CGM  Application  Profile" 

Computer  Graphics  and  applications  -  Graphics  Standards 
IEEE  Computer  Society,  August  1986 

Standards  in  the  Computer  Graphics  Industry  National 
Computer  Graphics  Association 


50 


2.6  MIL-STD-1388-1  (LSA)  AND  MIL-STD-1388-2  (LSAR) 

2.6.1  PURPOSE 

Logistic  Support  Analysis  (LSA)  is  a  regulatory 
requirement  in  accordance  with  DOD  Directive  5000.39 
"Acquisition  and  Management  of  Integrated  Logistic  Support  for 
Systems  and  Equipment"  and  is  required  in  all  material 
acquisition  programs.  LSA  is  the  application  of  engineering 
and  logistic  efforts  undertaken  during  the  acquisition  process 
to  assure  effective  and  economical  support  of  a  system 
procurement . 

The  tasks  required  for  performance  of  LSA  are  defined  in 
the  standard  MIL-STD-1388-1A  (LSA)  while  the  standard 
MIL-STD-1388-2A  Logistic  Support  Analysis  Record  (LSAR) 
defines  a  system  of  data  records,  computer  programs,  and 
output  reports  which  has  been  developed  to  document  LSA. 

MIL-STD-1388-1  defines  the  LSA  process,  as  a  result  of 
which  LSA  data  is  created.  MIL-STD-1388-2  defines  the 
requirements  for  the  LSAR,  through  which  much  of  that  data 
is  assembled,  managed,  and  reported. 


2.6.2  SCOPE 

LSA  is  used  to  obtain  a  reliable,  maintainable, 
transportable,  and  supportable  material  system  at  the  least 
cost  of  ownership  by  integrating  logistic  support 
considerations  into  the  system  and  detail  design  effort. 
MIL-STD-1388-1A  implements  the  LSA  guidelines  and  requirements 
established  by  DoD  Directive  5000.39.  The  goal  of 
MIL-STD-1388-1A  is  to  provide  a  single,  uniform  approach  for 
the  Military  Services  to  conduct  those  activities  necessary 
to: 

(1)  cause  supportability  requirements  to  be  an  integral 
part  of  system  requirements  and  design; 

(2)  define  support  requirements  that  are  optimally 
related  to  the  design; 

(3)  define  the  required  support  during  the  operational 
phase. 


The  purpose  of  MIL-STD-1388-2A  is  to  provide  a  uniform, 
organized,  yet  flexible,  technical  database  record  which 
consolidates  the  engineering  and  logistics  data  necessary  to 
identify  detailed  logistic  support  requirements  of  a  system. 
The  LSAR  database  records  are  used  to: 
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(1)  determine  the  impact  of  specific  design  features  on 
logistic  support; 

(2)  determine  how  the  proposed  logistic  support  system 
affects  system  reliability,  availability  and 
maintainability  characteristics; 

(3)  provide  input  data  for  tradeoff  analysis,  life  cycle 
cost  studies,  and  logistic  support  modeling  and 

(4)  provide  source  data  for  the  preparation  of  logistic 
products  including  training  and  technical  manuals, 
etc. 


During  a  contract  performing  phase,  a  Government  review 
team  will  regularly  review  the  contractor's  LSAR  reports  to 
ensure  that  support  system  development  is  adhering  to  the 
established  maintenance  plan  and  contract  requirement. 


2.6.3  RESPONSIBLE  DEVELOPMENT  ORGANIZATION 

The  Materiel  Readiness  Support  Activity  (MRSA)  of 
the  US  Army  Materiel  Command  was  delegated  major 
responsibilities  for  developing,  managing,  and  supporting  the 
LSA  process  as  the  DoD  Lead  LSA  Support  Activity.  Mr.  John 
Peer  (AV-745-3985)  is  currently  the  program  manager. 


2.6.4  IMPLEMENTATION  TOOLS/ AIDS 

1.  The  MIL-STD-1388-1A  standard  defines  and  details  the 
LSA  program  requirements,  however  there  was  no  source 
available  to  describe  the  procedures  and  techniques  for  LSA 
accomplishment.  Currently,  numerous  methodologies  exist 
within  DoD  and  industry  which  can  be  used  to  satisfy  many  of 
the  LSA  task  requirements.  MRSA  has  screened  and  compiled  a 
report  "Logistic  Support  Analysis  Techniques  Guide"  (AMC-P 
700-4,  March  1987)  which  provides  a  catalog  of  techniques, 
both  manual  and  automated,  currently  used  by  DoD  and  industry 
to  accomplish  the  LSA  tasks.  This  Guide  includes  more  than 
100  techniques  or  procedures  in  the  performance  of 
MIL-STD-1388-1A  and  catalogues  the  techniques  in  order  to 
facilitate  the  cross-fertilization  of  information  and  curtail 
the  efforts  to  perpetually  "reinvent  the  wheel". 

2.  The  Air  Force  sponsored  Unified  Data  Base  (UDB)  system 
focused  on  the  development  and  implementation  of  an  automated 
LSAR  and  associated  technology  to  accommodate  logistics 
information  prepared  under  the  provisions  of  MIL-STD-1388-2A. 
UDB  provides  a  user-friendly  automated  data  system  that 
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permits  on-line  entry  and  retrieval  of  LSAR  information.  UDB 
is  supported  by  the  Cullinet's  Integrated  Database  Management 
System  (IDMS)  on  an  IBM  (OS/MVS)  mainframe  compatible 
environment.  UDB  is  currently  used  by  the  SSN-21  program  in 
the  performance  of  LSAR  requirements. 


2.6.5  ON-GOING  DEVELOPMENT  ACTIVITIES 

The  format  and  data  elements  of  the  LSAR 
(MIL-STD-1388-2A)  is  being  modified  and  extended  by  MRSA  to 
include  relational  tables  that  comprise  an  LSAR  data  base. 
This  updated  standard  will  be  MIL-STD-1388-2B.  Concurrent  with 
this  effort,  a  new  on-line  DoD  LSAR  ADP  system  supported  by 
a  relational  data  base  is  being  developed  by  Battelle  and 
DACOM  with  funding  provided  by  the  OSD  CALS  Office.  Both  the 
updated  LSAR  standard  and  the  supporting  ADP  system  are 
planned  for  release  in  late  1990.  It  is  expected  that  other 
automation  tools  for  using  MIL-STD-1388-2B  will  be  developed 
by  both  Government  and  commercial  users. 


2.6.6  CALS  DATA  EXCHANGE  STANDARDS 

MIL-STD-1388-2  defines  the  format  and  content  of  the  LSAR 
and  the  structure  of  various  standard  reports  that  allow 
delivery  of  the  data  in  digital  form,  MIL-STD-1388-2  is  also 
a  technical  standard  for  delivery  of  LSAR  data  in  digital 
form. 


2.6.7  GOVERNMENT/ INDUSTRY  LSA  USER'S  GROUP 

MRSA  is  sponsoring  a  Government/ Industry  LSA  User's  Group 
meeting  which  meets  annually.  The  first  meeting  was  held  at 
Wright-Patterson  AFB  in  October  1988.  The  Navy  contact  for 
the  meeting  is  Mr.  Ron  Golenbioski  of  NAVAIR  Code  4111  (Tel. 
AV-222-0028) . 


2.6.8  DoD  LSA  NEWSLETTER  AND  ELECTRONIC  BULLETIN  BOARD 

MRSA  is  planning  to  publish  a  Newsletter  and  sponsor  an 
electronic  bulletin  board. 


2.6.9  TRAINING 

Army  MRSA  provides  no-cost  on-site  training  of  LSA/LSAR 
courses.  Contact  point  is  Mr.  David  Morgan  (AV-687-2156) . 
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2.7  THE  PRODUCT  DATA  EXCHANGE  SPECIFICATION  (PDES) 


2.7.1  PURPOSE 

The  Product  Data  Exchange  Specification  (PDES)  is  being 
developed  to  capture  information  about  a  product  in  a  computer 
sensible  format.  The  targeted  information  is  that  which  is 
needed  to  completely  define  a  product,  a  component  part  or  an 
assembly  of  parts  over  its  life  cycle  for  the  purpose  of 
design,  analysis,  manufacture,  test,  and  inspection.  This 
includes  the  product's  geometry,  topology,  logistics, 
tolerances,  attributes  and  features.  The  PDES  specification 
is  intended  to  one  day  exceed  the  capabilities  of  the  existing 
Initial  Graphics  Exchange  Specification  (IGES)  and  ultimately 
replace  that  standard. 


2.7.2  SCOPE 

The  first  draft  of  PDES  addresses  the  areas  of:  geometry; 
topology;  shape;  tolerances;  materials;  drafting;  mechanical 
products;  Architecture,  Engineering,  and  Construction  (AEC) 
(the  AEC  core  and  ship  structure  models)  ;  electrical;  and 
Finite  Element  Modeling  (FEM) .  These  models  are  part  of  the 
draft  proposal  submitted  to  the  International  Standards 
Organization  (ISO)  for  approval.  The  specification  is 
currently  being  developed  and  is  not  yet  a  standard;  but  the 
draft  is  proceeding  through  the  review  and  approval  process 
needed  to  create  an  international  standard.  Some  of  the  models 
within  the  present  specification  may  change,  or  even  be 
withdrawn  from  the  draft  proposal,  depending  on  the  results 
of  the  ISO  ballot. 

The  direction  in  which  PDES  implementations  are  intended 
to  advance  is  specified  by  the  four  levels  of  implementation. 
These  levels  specify  the  manner  in  which  data  is  to  be 
exchanged  or  shared. 

Level  1:  File  Exchange  (targeted  for  first  version) 

Level  2:  Working  Form  Exchange/with  access  software 
(future) 

Level  3:  Database  Exchange  (future) 

Level  4 :  Knowledge  Base  Exchange  plus  active  constraint 
checking  (future) 

These  concepts  are  being  clarified  by  the  IGES/PDES 
organization  and  are  intended  to  create  increasingly  effective 
methods  of  data  exchange/ sharing.  A  Level  1  implementation 
exchanges  PDES  files  in  the  same  manner  that  IGES  files  are 
exchanged  today.  In  a  level  2  implementation,  the  data  will 
be  translated  into  or  out  of  a  standard  working  form  (which 
may  be  different  than  the  exchange  format  file)  where  it  can 
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be  accessed  by  a  standard  software  program.  This  means  that 
a  standard  software  program  would  be  used  by  programmers  to 
get  data  into  and  out  of  the  standard  working  form.  The  IGES 
standard  does  not  have  this  feature;  vendors  were  required  to 
write  their  own  software  programs  to  access  the  IGES  file  and 
some  vendors  erroneously  left  out  parts  of  the  IGES  file, 
causing  problems  for  the  system  that  receives  the  file.  A 
Level  3  implementation,  will  translate  the  data  into  and  out 
of  a  data  base  management  system  (DBMS) .  This  level  will  allow 
access  to  the  PDES  DBMS  by  standard  database  languages  such 
as  SQL.  A  Level  4  implementation  will  also  translate  the  data 
into  and  out  of  a  DBMS,  and  will  enforce  any  constraint  rules 
specified  in  the  PDES  standard.  For  example,  if  the  ship 
structures  model  states  that  a  distribution  system  must  be 
contained  within  the  hull,  the  constraint  rules  would  check 
to  ensure  that  this  condition  is  not  violated. 

PDES  is  described  as  having  a  three  schema  approach,  the 
application,  logical,  and  physical  layers  (or  schemas).  The 
application  layer  presents  the  user's  view  of  product  data  in 
his  particular  application  from  his  viewpoint.  This  view  is 
developed  and  represented  through  graphical  models  specific 
to  a  given  application  and  are  developed  using  an  information 
analysis  methodology  (i.e.  IDEF1X  or  NIAM) .  All  application 
models  are  mapped  into  the  logical  layer,  which  provides  a 
single  abstract  view  of  the  collection  of  application  area 
data;  similar  concepts  in  the  different  application  models  are 
integrated  into  common  general  entities.  The  logical  layer 
serves  to  shelter  the  application  layer  from  the  details  of 
the  physical  layer  (and  shelters  the  engineer  from  the 
internal  computer  representation  of  the  data) .  The  logical 
layer  is  described  using  an  information  description  language 
(called  Express) .  The  generic  entities  in  the  logical  layer 
are  represented  in  the  physical  layer  in  a  machine  readable 
form.  The  physical  layer  contains  the  actual  file  format 
definitions  and  a  representation  of  the  application's  models 
as  a  sequential  file  in  an  unambiguous  context-free  grammar, 
which  is  suitable  for  processing  by  computer  software. 


2.7.3  STATUS  AND  PLANNED  EXTENSIONS 

The  PDES  specification  is  divided  into  a  number  of 
different  chapters,  which  are  called  clauses,  with  a  400  page 
limit  per  clause.  Most  clauses  are  normative,  the  ISO 
expression  for  required,  and  cover  the  Express  definitions  of 
entities,  test  methods,  definition  of  the  Express  language, 
physical  file  structure  and  the  mapping  of  entities  from 
Express  to  the  physical  file  structure.  Others  are 
informative,  meant  as  helpful  reference  material.  These  areas 
include  the  IDEF  or  NIAM  information  models  and  information 
on  development  support. 
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The  Express  language  used  by  PDES  is  a  formal  language 
designed  for  communicating  information  concerning  data.  The 
language  is  similar  to  the  portions  of  computer  programming 
languages  that  declare  the  structure  of  data  (as  does  the  ADA 
language) .  Express  is  not  intended  to  be  used  directly  by  the 
computer,  but  will  be  mapped  (or  compiled)  into  a  data 
definition  language  or  a  programing  language. 

Work  is  underway  for  the  future  PDES  version  2.  The 
models  under  consideration  for  addition  to  PDES  are:  AEC, 
Electrical,  Form  Features,  FEM,  and  Materials  models.  Other 
new  information  models  being  developed,  but  not  ready  for 
consideration  are:  Manufacturing,  Logistics,  Composite 
Materials,  Vehicle  systems,  and  Kinematics  models. 


2.7.4  PROBLEMS 

The  PDES  specification  is  being  developed  by  a  volunteer 
organization,  IGES/PDES,  which  causes  the  development  effort 
to  proceed  slowly.  There  are  problems  with  the  continuity  of 
individuals  participating  in  the  PDES  development,  dependent 
upon  their  organizations  support  of  their  PDES  involvement. 
The  specification  is  also  working  towards  international 
standardization,  which  increases  the  time  required  to 
officially  release  the  document.  The  requirements  that  the 
PDES  specification  is  trying  to  meet  are  not  clearly  stated 
within  the  PDES  document.  The  requirements  are  buried  within 
various  sections  and  within  the  models  themselves.  This 
increases  the  difficulty  of  determining  if  the  specification 
actually  meets  its  requirements. 


2.7.5  EXTENT  AND  NATURE  OF  USER  AND  VENDOR  SUPPORT 

PDES  is  currently  under  development.  The  document  is  a 
draft,  not  yet  approved  by  ISO,  and  no  official  PDES 
translators  are  available.  A  few  experimental  implementations 
of  portions  of  the  current  PDES  draft  document  have  been 
developed,  but  these  prototype  translators  will  probably  be 
quite  different  from  the  final  translators  because  the  basic 
specification  will  probably  change.  A  prototype  developed  by 
the  Chair  of  the  Physical  File  Committee,  Jeff  Altemueller  of 
McAir,  indicates  that  the  processing  time  required  by  PDES 
translators  and  the  size  of  the  file  created  will  be  less  than 
that  required  by  IGES  processors  and  files. 

There  is  a  great  deal  of  support  for  the  standard  within 
the  industry  community.  The  IGES/PDES  voluntary  organization 
is  developing  the  specification,  with  a  participation  of  236 
members  at  the  April  1989  meeting.  There  is  also  a  non-profit 
corporation,  PDES,  Inc.  that  has  been  set  up  to  improve  the 
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quality  and  to  accelerate  the  implementation  of  the  PDES 
specification. 


2.7.6  STRUCTURE  OF  DEVELOPMENT  ORGANIZATION 

PDES  is  being  developed  by  the  IGES/PDES  Voluntary 
Organization  under  the  direction  of  the  Project  Manager,  Tony 
Day  of  Sikorsky  Aircraft  UTC.  The  specification  is  being 
developed  in  a  bottom  up  manner.  Which  means  that  the 
originating  technical  committees  start  the  process  by  modeling 
their  own  area  of  expertise  in  the  graphical  modeling  language 
IDEF1X  or  NIAM.  After  review  and  approval  within  the  technical 
committee,  the  committee  translates  the  models  into  the 
logical  layer  representation  of  Express.  The  Express  Model 
and  the  IDEF1X  or  NIAM  model  are  then  sent  to  the  Integration 
Committee,  who  will  integrate  the  model  with  the  other  models 
in  the  Integrated  Product  Information  model  (IPIM) .  The 
Integration  committee,  along  with  the  model  owners,  will 
resolve  conflicts  and  ambiguities  between  the  different  models 
and  clarify  the  model  interfaces. 

The  integrated  set  of  models  is  sent  to  the  International 
Standards  Organization  (ISO) .  At  ISO  the  specification  goes 
through  a  formal  review  and  balloting  process  with  each  nation 
casting  one  vote  on  the  approval  or  disapproval  of  the 
specification  as  an  international  standard.  The  U.S. 
representative  to  ISO  is  the  American  National  Standards 
Institute  (ANSI)  .  PDES  is  the  name  for  the  Product  Data 
Exchange  Specification  effort  within  the  United  States;  within 
the  international  community  it  is  known  as  STEP,  the  Standard 
for  the  Exchange  of  Product  Model  Data. 

ISO  approved  the  PDES  document  which  was  submitted  for 
ISO  registration  in  November,  1988,  as  a  formal  Draft 
Proposal.  The  document  submitted  to  ISO  contains  data  models 
which  can  describe  only  a  subset  of  the  product  data  required 
to  represent  a  given  product  and  is  intended  to  permit 
international  review  and  to  serve  as  a  check  point  for  the 
PDES  development  effort.  The  ISO  registration  does  not  imply 
approval  of  the  specifications  content,  but  does  begin  the 
international  balloting  that  will  produce  consensus  approval 
of  the  specification.  The  final  stages  of  ISO  standardization 
are  the  elevation  of  the  Draft  Proposal  to  the  status  of  Draft 
International  Standard  (earliest  possible  date  January 
1990) and  finally  to  International  Standard  (earliest  possible 
date  January  1991).  The  approved  PDES  version  1.0  standard 
will  most  likely  be  a  subset  of  the  Draft  Proposal. 
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2.7.7  TESTING  AND  VALIDATION 


The  various  technical  committees  within  the  voluntary 
organization  conduct  "walk  throughs"  and  test  their  own  models 
internally,  but  there  is  currently  no  formal  test  that  the 
models  must  pass  before  release  to  the  integration  committee. 
There  is  no  designated  committee  in  the  voluntary  PDES  group 
that  tests  and  validates  the  models  before  they  are  released. 
The  non-profit  group,  PDES,  Inc.,  does  have  a  test  and 
validation  team  for  the  models.  The  models  currently  being 
tested  by  PDES,  Inc.  are  the  geometry  and  topology  models.  The 
Product  Structure  Configuration  Model  (PSCM)  and  tolerance 
model  are  being  placed  under  PDES,  Inc.  configuration  control 
prior  to  being  sent  to  their  test  and  validation  team.  The 
shape  interface  model  was  sent  back  to  the  voluntary 
organization  with  the  request  that  it  be  reworked.  The  results 
of  the  PDES,  Inc.  testing  are  returned  to  the  IGES/PDES 
voluntary  organization,  where  any  errors  or  inconsistences  are 
addressed. 


2.7.8  REFERENCE  AND  IMPLEMENTATION  DOCUMENT 
AVAILABLE 

The  PDES  draft  proposal  can  be  ordered  from  the  National 
Technical  Information  Service  (NTIS)  at  $169.95  for  a  paper 
copy  and  $50.50  for  a  microfiche  copy.  Use  the  number  PB  89 
144  794  to  reference  the  document.  Order  from: 

National  Technical  Information  Service  (NTIS) 

5285  Port  Royal  Road 
Springfield,  VA  22161 
Telephone:  (703)487-4650 


Other  documents  that  provide  more  information  about 
PDES/STEP  are: 

Outline  of  the  Integrated  Product  Information  Model 
and  Express,  Nigel  Shaw  and  Jon  Owen,  Dept,  of 
Mechanical  Engineering,  University  of  Leeds,  Leeds 
LS2  9JT,  United  Kingdom,  December  1988. 

(A  description  of  the  Express  language  and  a 
discussion  of  the  IPIM  (Integrated  Product 
Information  Model)  and  its  integration.) 


PDES  Initiation  Activities,  A  Reporting  of  the  PDES 
Initiation  Activities,  Brad  Smith,  National 
Institute  of  Standards  and  Technology,  May  20,  1986. 
(This  report  is  a  summary  of  the  PDES  activities 
between  November  1984  through  April  1986.  This 
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document  would  be  useful  for  background  and 
historical  information.) 


Welcome. to  the  Initial  Graphics  Exchange 
Specification/Product  Data  Exchange  Specification, 
Bradford  Smith,  National  Institute  of  Standards  and 
Technology,  January,  1989. 

(An  introduction  to  the  IGES/PDES  Organization  with 
history  of  the  group,  the  scope  and  plans  of  the 
technical  committees,  and  titles  of  the  committee 
reference  documents.) 
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2.8  ELECTRONIC  DESIGN  INTERCHANGE  FORMAT  (EDIF) 

2.8.1  PURPOSE 

The  Electronic  Design  Interchange  Format  (EDIF)  is 
intended  for  the  "information  transfer  at  all  levels  of 
electronic  design...  from  design  capture  and  verification 
through  layout,  manufacture,  and  test  of  printed  circuit 
boards  and  application-specific  integrated  circuits". 
(Exchange  Standards  for  Electronic  Product  Data,  M.L.  Brei) . 
EDIF  handles  partial  and  complete  design  data  and  is  a  public 
domain,  machine  readable  format.  EDIF  is  one  of  the  candidates 
for  the  exchange  of  electronic  product  definition  data  in  the 
Computer-Aided  Acquisition  and  Logistic  Support  (CALS)  effort 
for  inclusion  in  CALS  phase  1.2. 

2.8.2  SCOPE 

EDIF  version  2.2.0  covers  the  areas  of  integrated  circuit 
(IC)  and  printed  circuit  board  (PCB)  layouts,  schematics, 
documentation  and  physical  design  rules.  It  is  also  being  used 
for  very  large-scale  integration  (VLSI)  design.  EDIF  is  not 
intended  to  cover  3D  mechanical  drawings  and  analyses,  system 
manufacturing  information  or  other  system  design  functions. 
Unlike  the  (Very  High  Speed  Integrated  Circuit)  VHSIC  Hardware 
Description  Language  (VHDL) ,  EDIF  is  a  non-executable  data 
format,  an  ASCII  data  file.  EDIF  also  has  international 
appeal,  having  been  accepted  for  use  in  data  exchange  by  the 
European  electronics  community. 

2.8.3  STATUS  AND  PLANNED  EXTENSIONS 

One  of  the  design  intents  of  EDIF  was  to  make  the 
specification  easily  extendable,  this  is  accomplished  through 
the  use  of  keywords  in  the  format.  New  abilities  are  added  to 
the  specification  by  the  definition  of  new  keywords. 

There  has  been  concern  expressed  over  the  number  of 
standards  for  the  exchange  of  electrical  product  data.  A 
meeting,  chaired  by  Mr.  S.L.S.  Barnes  of  the  British  Standards 
Institution,  was  held  to  discuss  the  boundaries  of  EDIF  and 
the  Product  Data  Exchange  Specification  (PDES)  and  an  attempt 
is  being  made  to  harmonize  the  standards  which  apply  to 
electronic  product  data. 


2.8.4  EXTENT  AND  NATURE  OF  USER  AND  VENDOR  SUPPORT 

EDIF  was  originally  designed  for  the  exchange  of  semi¬ 
custom  design  data  between  designers  and  foundries.  The 
development  organization  was  formed  in  November,  1983,  because 
of  several  companies  dissatisfaction  with  existing  data 
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exchange  formats  for  Integrated  Circuit  (IC)  designs.  The 
electronics  companies  that  developed  the  original 
specification  are  Texas  Instruments,  National  Semiconductor, 
Motorola,  the  University  of  California  at  Berkeley,  Tektronix, 
Daisy  Systems,  and  Mentor  Graphics. 

EDIF  is  widely  accepted  within  the  European  communities. 
Extensive  user  groups  have  been  formed  in  Britain,  West 
Germany  and  Japan. 

2.8.5  STRUCTURE  OF  DEVELOPMENT  ORGANIZATION 

The  EDIF  organization  is  an  ad  hoc  voluntary  consortium 
composed  of  members  from  industry  and  academia.  The 
organization  is  guided  by  a  steering  committee  which  makes 
the  needed  policy  decisions.  Next  in  the  hierarchy  is  the 
Technical  Committee,  which  coordinates  the  work  of  the 
technical  subcommittees  and  holds  responsibility  for  the 
technical  content  of  the  specification.  Then  there  are  the 
technical  subcommittees,  which  are  composed  of  the  technical 
specialists  who  make  recommendations  to  the  Technical 
Committee  and  do  the  technical  work.  One  of  the  primary  goals 
of  the  EDIF  organization  is  to  be  able  to  release  a 
specification  quickly,  to  be  able  to  respond  to  the  changing 
needs  of  the  electrical  industry. 


2.8.6  REFERENCE  AND  IMPLEMENTATION  DOCUMENTS  AVAILABLE 

Electronic  Design  Interchange  Format,  The  EDIF  User's 
Group,  Design  Automation  Department,  Texas  Instruments,  PO  Box 
225474,  MS3668 ,  Dallas,  Texas  75265 

Exchange  Standards  For  Electronic  Product  Data, 
Information  For  Defense  Analyses  (IDA)  Memorandum  Report  M- 
434,  October  1988,  prepared  for  the  Office  of  the  Assistant 
Secretary  of  Defense. 


61 


2.9  VHSIC  (VERY  HIGH  SPEED  INTEGRATED  CIRCUIT)  HARDWARE 
DESCRIPTION  LANGUAGE  (VHDL) ,  IEEE  1076-1988 


2.9.1  PURPOSE 

The  VHSIC  Hardware  Description  Language  (VHDL)  is  an 
Institute  of  Electrical  and  Electronics  Engineers  (IEEE) 
standard,  IEEE  1076-1988,  for  behavioral  models  of  electronic 
components.  Very  High  Speed  Integrated  Circuit  (VHSIC)  designs 
can  be  created  in  VHDL  and  then  exchanged  between  computer 
systems.  VHDL  is  similar  to  a  general  computer  programming 
language,  in  that  it  can  be  output  once  a  model  is  developed 
and  then  compiled  or  interpreted  into  another  system.  It  is 
one  of  the  candidates  for  the  exchange  of  product  definition 
data  for  electronics,  in  CALS  phase  1.2. 


2.9.2  SCOPE 

VHDL  addresses  syscem  level  design,  simulation  of  the 
system  and  testing  of  the  system.  It  is  made  up  of  three 
different  "views"  of  the  model:  the  behavioral  view,  the 
structural  view  and  the  data  flow  view.  The  behavior  view  is 
an  algorithmic  description  of  the  model,  (it  is  the  part  like 
a  programming  language) .  The  structural  view  is  a  simple 
netlist  description  of  the  component.  And  the  data  flow  view 
describes  a  network  of  signals  and  transformers. 


2.9.3  STATUS  AND  PLANNED  EXTENSIONS 

The  full  VHDL  standard  is  very  large,  its  sheer  size 
makes  full  implementation  difficult  and  time  consuming.  This 
raises  the  possibility  its  implementations  may  be  done  in  the 
same  manner  as  occurred  with  the  IGES  standard,  where  every 
vendor  implemented  his  own  unique  subset  of  the  standard. 
Subsets  are  being  proposed  for  VHDL  to  help  speed 
implementation  and  aid  full  data  exchange.  One  proposed  subset 
is  a  design  exchange  subset,  which  "provides  for  the  movement 
of  behavioral,  functional  and  gate-level  models  between 
simulators,  as  well  as  component  and  netlist  data  for  CAD 
tools".  Another  proposed  subset  is  the  core  subset  that 
"permits  minimal  functional  format  translation,  without  timing 
or  concurrency  data"  (February,  1989  Computer  Design) .  These 
subsets  are  being  developed  by  the  VHDL  Design  Exchange  Group, 
lead  by  Mo  Shahdad,  president  of  CAD  Language  Systems,  Inc. 

The  Electronics  Industries  Association  (EIA)  plans  to 
develop  standards  for  behavior  simulation  models  written  in 
VHDL  (VHSIC  Hardware  Description  I  guage) .  According  to  the 
EIA,  "Initial  emphasis  will  be  to  j  vide  defense  electronics 
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contracts  with  the  ability  to  comply  with  DoD  regulations 
concerning  the  delivery  of  contractual  data  in  digital  form” 
(February  1989,  CAD  Report). 


2.9.4  PROBLEMS 

VHDL  simulators  need  basic  component  model  libraries  in 
VHDL  of  standard  components  to  realize  the  simulators  true 
productivity,  but  the  cost  of  developing  these  libraries  is 
high.  An  estimate  of  $15  to  $30  million  was  given  in  the  CALS 
Report,  February  1989.  Component  models  are  developed  and 
often  marketed  by  third  party  companies.  With  a  neutral 
standard,  there  is  concern  that  these  models  can  be  easily 
"pirated”.  The  VHDL  Ad  Hoc  Committee  of  the  Electronics 
Industries  Association  (EIA)  is  proposing  a  solution  to  this 
problem  with  the  concept  of  an  industry  consortium  to  share 
the  cost  of  developing  VHDL  models. 

While  the  standard  defines  the  syntax,  there  are  few 
rules  for  how  models  should  be  created  in  VHDL.  When  there  are 
discrepancies  between  two  VHDL  descriptions  "there's  no  means 
to  validate  which  description  is  correct"  -  Feb.  1989  Computer 
Design. 


2.9.5  EXTENT  AND  NATURE  OF  USER  AND  VENDOR  SUPPORT 

Mentor  Graphics  has  announced  the  first  full 
implementation  of  IEEE  STD-1076  with  their  software  product 
System-1076,  in  February  1989.  They  chose  VHDL  because  "First, 
VHDL  supports  multiple  levels  of  abstraction,  so  it  maps  very 
well  into  the  way  a  designer  thinks  and  works.  Second,  VHDL 
is  the  industry-standard  hardware  description  language", 
according  to  Geoff  Bunza,  general  manager  of  Mentor's  design 
and  analysis  division.  Their  product  will  be  available  in  the 
3rd  quarter  of  1989. 

Other  vendors  that  support  VHDL  are  Vantage  Analysis  with 
a  schematic  to  a  VHDL  simulator  named  the  Electronic 
Spreadsheet.  Silicon  Compiler  Systems  and  Intermetric  both 
provide  compiled  data  simulators.  These  compile  the  VHDL  file 
into  the  companies  own  simulator  database. 

There  are  many  other  hardware  description  languages 
(HDLs)  already  existing  within  industry.  Some  of  these  were 
created  by  adding  extensions  to  computer  programming 
languages,  while  others  are  special  languages  that  contain 
data  structures  for  some  electronic  hardware  such  as  a 
register,  Random  Access  Memory  (RAM) ,  and  Read  Only  Memory 
(ROM)  .  But  none  of  these  HDLs  have  reached  the  status  of  a 
national  standard  as  VHDL  has. 
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2.9.6  STRUCTURE  OF  DEVELOPMENT  ORGANIZATION 

VHDL  was  started  by  the  Air  Force  through  the  Very  High 
Speed  Integrated  Circuit  (VHSIC)  Program  Office.  A  team  of 
Intermetrics,  IBM  and  Texas  Instruments  formed  the  initial 
draft  of  the  language.  It  was  sent  to  the  IEEE  for  approval 
as  a  national  standard.  IEEE  Design  Automation  Standards 
Subcommittee  (DASS)  is  now  maintaining  the  language. 


2.9.7  REFERENCE  AND  IMPLEMENTATION  DOCUMENTS  AVAILABLE 

IEEE  VHDL  1076-1988,  the  VHDL  standard. 

MIL-STD-454 ,  applies  to  all  electronic  equipment.  Copies 
may  be  ordered  from:  Department  of  Defense  Single  Stock 

Point,  Commanding  Officer,  Naval  Publications  and  Forms  Center 
(NPFC) ,  5801  Tabor  Avenue,  Philadelphia,  PA  19120. 

Exchange  Standards  for  Electronic  Product  Data, 
Information  for  Defense  Analysis  (IDA)  Memorandum  Report 
M-434,  October  1988,  prepared  for  the  Office  of  the  Assistant 
Secretary  of  Defense. 

The  Electronic  Industries  Association  (EIA)  is  developing 
a  set  of  standards  expected  to  be  available  in  1989: 

EIA  VHDL  Commercial  Component  Model  Specification 
EIA  VHDL  Blank  Detail  Specification 
EIA  VHDL  Timing  Module  Specification 
EIA  Engineering  Practices  for  Quality  Assurance  of 
Standard  Part  Models 

These  standards  will  be  available  through  the  Electronic 
Industries  Association,  2001  Eye  Street,  N.W.  ,  Washington, D.C. 
20006. 
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2.10  OFFICE  DOCUMENT  ARCHITECTURE  (ODA) ,  ISO  8613 

2.10.1  PURPOSE 

The  two  chief  purposes  of  ODA  are  to  facilitate  document 
interchange  such  that: 

(1)  Different  types  of  content  (i.e.  text,  raster 

graphics,  vector  graphics,  data,  photographic 

images,  etc.)  can  all  appear  in  a  document  and  be 
transferred  easily  to  another  computer  system  with 
another  operating  system. 

(2)  Requirements  of  editing,  formatting,  and  internal 
storage  can  be  communicated  in  the  same  file  of 
information,  but  the  emphasis  is  on  transfer  of 
layout  information  which  is  what  ODA  terms  as 
document  "architecture.” 

ODA  allows  the  sharing  of  text  between  or  among  systems 
in  which  documents  have  been  composed  using  any  standard 
character  set,  or  raster  graphics  based  on  the  International 
Consultative  Committee  on  Telegraphy  and  Telephony  (CCITT)  (an 
international  standards  organization) ,  or  vector  graphics 
based  on  the  Computer  Graphics  Metafile  (CGM) .  ODA  works  with 
the  layout  of  a  document  with  its  specified  format,  and  is  not 
concerned  with  such  logical  elements  as  titles,  heads, 
subheads,  and  paragraphs,  but  only  with  the  content  of  the 
document,  represented  as  strings  of  character  data.  ODA 
provides,  to  a  limited  extent,  for  the  preservation  of  a 
document's  structure,  but  is  much  weaker  in  this  function  than 
is  the  Standard  Generalized  Markup  Language  (SGML) .  The  role 
of  ODA  with  respect  to  CALS  has  not  been  fully  defined.  In 
MIL-STD-1840A  and  MIL-M-28001  there  are  references  to  ODA 
which  allow  the  possible  future  inclusion  of  ODA  as  a  CALS 
standard. 

ODA  provides  for  the  representation  of  documents  in  three 
forms: 

(1)  Formatted  form  in  which  documents  are  presented 
(output)  as  intended  by  the  originator. 

(2)  Processable  form  in  which  documents  may  be  edited  and 
formatted  by  the  recipient. 

(3)  Formatted  processable  form  which  allows  documents  to 
be  presented  and/or  edited  and  reformatted. 


2.10.2  TYPICAL  APPLICATIONS 

ODA  is  especially  useful  for  processing  one-time 
documents  in  which  the  preservation  and  conformance  of  a 
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logical  structure  is  not  critical.  ODA  was  initially 
developed  for  the  processing  of  office  type  documents. 

ODA  provides  for  the  representation  of  documents 
containing  various  types  of  content  including  character  data, 
raster-scanned  images,  and  vector  graphics,  all  of  which 
conform  to  international  standards. 


2.10.3  STATUS 

ODA  is  defined  by  an  international  standard,  which  is 
currently  competing  with  SGML  and  its  extensions  to  become  the 
preferred  system  for  Computer  Aided  Logistics  Support  (CALS) 
technical  publications.  Despite  ODA's  development  by  academia 
and  industry,  it  has  received  less  attention  from  the  CALS 
community  than  has  SGML.  ODA  provides  few  attributes  for 
representing  logical  structure,  nor  does  it  provide  a 
"parsing”  capability.  It  should  be  noted  that  by  making  SGML 
the  CALS  standard  for  exchange  of  technical  publications,  DoD 
has  decided  that  logical  structure  of  technical  publications 
is  a  requirement.  By  using  SGML,  compliance  of  the  logical 
structure  can  be  ensured. 


2.10.4  PLANNED  EXTENSIONS 

ISO,  in  conjunction  with  CCITT,  is  working  on  future 
extensions  to  ODA,  including  the  following: 

*  Document  access  and  manipulation  functions,  which 
will  provide  support  for  applications  such  as 
remote  document  editing  and  data  entry. 

*  Manipulation  of  color  information. 

*  The  use  of  data  in  documents  to  be  used  in 
applications  such  as  spreadsheets,  processable 
tables,  and  business  graphics. 

*  The  inclusion  of  security  features. 

*  The  addition  of  annotations  and  the  control  of 
document  revision. 

*  The  inclusion  of  audio  and  voice  information. 

*  Enhanced  layout  features. 

CCITT  has  recently  approved  a  new  series  of  communication 
protocols  to  be  used  in  conjunction  with  their  T.410  series 
of  Recommendations.  These  new  protocols  (T.430)  will  be  used 
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with  the  T.410  series  as  the  basis  of  further  document 
interchange  services  that  will  be  developed  during  the  next 
study  period  (1989-  1992). 

Subsets  of  ODA  standards,  referred  to  as  document 
application  profiles  (DAPs) ,  are  being  developed  by  several 
users.  DAPs  will  be  documented  by  various  standards-making 
organizations,  eg.,  ISO  and  CCITT,  and  included  will  be 
information  about  how  these  DAPs  are  to  be  used.  Other 
publications  will  define  equipment  characteristics  and 
communication  requirements  for  these  services. 

Several  user/manufacturer  groups  are  now  developing  a 
hierarchically  related  set  of  DAPs  that  will  make  possible  the 
interchange  of  documents  ranging  from  simple  text  documents 
to  highly-structured  multi-media  documents  containing  text  and 
graphics,  including  documents  produced  with  desk-top 
publishing  systems.  International  groups  are  involved  in  this 
effort  and  joint  meetings  are  being  held  to  clear  up 
differences. 

Important  initiatives  are  going  on  in  both  Europe  and  in 
the  USA.  The  EXPRES  (Experimental  Research  in  Electronic 
Submission)  project  is  underway  in  the  USA,  with  Carnegie 
Mellon  University  and  the  University  of  Michigan  as  the  main 
participants.  These  initiatives  are  designed  to  demonstrate 
the  interchange  of  information  among  different  proprietary 
systems  by  the  use  of  ODA.  Developers  also  want  to  produce 
document  editing  systems  and,  thus,  further  enhance  ODA's 
capabilities. 


2.10.5  DEVELOPMENT  ORGANIZATION 

ISO  is  the  development  organization  of  ODA  and  there  are 
two  methods  in  which  changes  may  be  made  to  the  standards: 

(1)  A  "defect  report"  can  be  issued  to  ISO-member 
organizations  (ANSI  in  the  USA)  by  a  user,  following 
which  a  proposed  solution  is  promulgated  by  that 
organization. 

(2)  Extensions  to  the  standard  can  be  issued  directly 
by  a  part  of  the  International  Standards 
Organization  (ISO) . 


2.10.6  TESTING  AND  VALIDATION 

ODA  has  been  tested  and  documented  by  both  ISO  and  CCITT 
as  of  early  1988.  As  future  extensions  are  implemented,  they 
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and  their  interfaces  with  the  existing  ODA  system  will  have 
to  be  tested. 


2.10.7  REFERENCE  AND  IMPLEMENTATION  DOCUMENTS 

ISO  8613,  "International  Processing:  Text  and  Office 
Systems-Of f ice  Document  Architecture  (ODA)  and  Interchange 
Format,"  Parts  1-8  is  very  theoretical  and  requires  careful 
reading.  The  CCITT  approved  a  series  (T.410)  of 
recommendations  also  in  1988,  "Open  Document  Architecture 
(ODA)  and  Interchange  Format,"  the  contents  of  which  are 
nearly  identical  to  those  of  ISO  8613.  Further,  ECMA  published 
a  standard  in  1985,  "ECMA-101,"  which  explains  both  formatted 
and  processable  type  documents.  The  document  has  been  used  as 
a  basis  for  developing  prototypes  of  ODA-based  systems. 
"Document  Transfer  and  Manipulation  (DTAM) :  Service  and 
Protocols,"  a  new  set  of  communication  protocols  was 
published  as  the  CCITT  T.430  series  of  Recommendations  in 
1988. 


2.10.8  SUMMARY 

ODA  is  an  international  standard  which  facilitates  the 
computer  interchange  of  documents  in  both  revisable 
("processable")  and  final  ("formatted")  forms.  ODA  allows 
computing  systems  of  different  manufacture  to  have  a  common 
understanding  of  the  semantics  of  interchanged  documents. 
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2.11  CALS  STANDARDS  SUMMARY 


The  following  charts  identify  each  current  and  future 
CALS  data  interchange  standard  described  and  relates  these 
CALS  standards  to  their  intended  applications. 


Chart  1.  CURRENT  CALS  DATA  EXCHANGE  STANDARDS 


DoD 

Standard 

ADDlications 

Descriotion 

MIL-D-1840A 

Tech  Pubs  and 

Product  Data 

Provides  rules  for 
organizing  files  of 
digital  data  for  a 
complete  deliverable 
document 

MIL-D-28000, 

IGES 

CAD,  Vector  Graphics 

-  Engrg  Drawings 

-  TM  Illustrations 
(optional) 

-  Elec  Applications 

-  NC  Manufacturing 

Data  is  transferred  as 
a  set  of  entities  with 
associated 
non-geometric  data 

1 

MIL-M-28001/ 

SGML 

Automated  Publishing 
-  Tech  Manuals 

Basic  structure  of  a  text 
document  is  transferred 
by  using  a  set  of  , 

mark-up  tags  ! 

MIL-R-28002 , 
Raster 

Raster  Scanned  Images 

-  Engrg  Drawings 

-  TM  Illustrations 

Raster  images  stored  as 
a  series  of  lines 
consisting  of  arrays  : 

of  dots. 

MIL-D-28003, 

CGM 

Vector  Graphics 

-  TM  Illustrations 
(preferred) 

Illustration  data  is 
transferred  in  vector 
format. 
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Chart  2.  FUTURE  CALS  DATA  EXCHANGE  STANDARDS 


Standard  Application 

LSAR  MIL-D-1388  Being  Revised  to  Facilitate 

Logistic  Support  Logistic  Support  Use  of  Relational  DBMS 

Analysis  Record  Technology 


PDES  Complete  Product  Definition  for 

Product  Data  Applications  Over  Life  Cycle 

Exchange 
Specification 


EDIF  Electronics  Product  Definition 

Electronic  Data 

Interchange 

Format 


VHDL  Electronics  Product  Definition 

VHSIC  Hardware 

Description 

Language 


ODA  Presentation  and  Layout  -  Technical 

Office  Document  Publications 

Arch  and 

Interchange 

Format 


70 


3.0  OVERVIEW  OF  SELECTED  INDUSTRY  APPROACHES  TO  DIGITAL  DATA 

EXCHANGE 

This  section  provides  a  brief  overview  of  selected  industry 
approaches  to  digital  data  exchange.  It  is  not  intended  to 
represent  a  complete  description  of  any  company's  activities  but 
rather  to  provide  an  insight  into  each  company's  recognition  of  the 
importance  of  digital  data  exchange  and  their  approach  to 
addressing  the  problem.  The  companies  highlighted  are  McAir, 
Newport  News  Shipbuilding,  Northrop  Aircraft  Division,  and 
Westinghouse  Electronic  Systems  Group. 
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3.1  OVERVIEW  OF  McAIR'S  APPROACH  TO  DIGITAL  DATA  EXCHANGE 


3.1.1  CORPORATE  OBJECTIVE 

McAir  has  made  a  corporate  commitment  to  advancing  and 
improving  product  data  exchange  practice  by  means  of  data 
sharing  and  standards.  McAir 's  goal  is  to  improve  weapon 
systems  affordability  by  managing  information  as  a  critical 
resource  to  design,  manufacture,  and  support  the  product  using 
advanced  information  technology. 


3.1.2  STRATEGY  TO  ACCOMPLISH  THE  OBJECTIVE 

McAir' s  strategic  vision  to  accomplish  this  goal  is 
through  R&D  efforts  in  information  modeling  and  digital 
exchange  technology,  and  through  the  use  of  a  shared  data  base 
which  can  be  accessed  by  design  and  manufacturing  engineers, 
logisticians  and  for  technical  manuals,  and  computer  based 
training,  etc. 


3.1.3  APPROACH 

The  McAir  approach  to  achieving  this  objective  is: 

-  to  participate  in  digital  data  exchange  standards 
development  efforts, 

-  to  develop  enabling  technology, 

-  to  develop  prototype  digital  product  model 

-  to  proceed  towards  integrating  the  work  processes 
within  their  company. 


3.1.4  MAJOR  ACTIVITIES  IN  SUPPORT  OF  APPROACH 

Product  Definition  Data  Interface  (PDDI)  -  PDDI  is  an 
Air  Force  sponsored  R&D  project  which  was  initiated  in  1982 
and  completed  in  1987.  The  PDDI  project  demonstrated  a 
prototype  system  targeted  at  the  functional  replacement  of 
engineering  drawings  with  the  development  of  a  complete 
digital  part  model  to  serve  as  an  interface  between 
engineering,  manufacturing  and  logistic  support.  In  the  PDDI 
project,  the  shared  data  base  provides  an  integrated  product 
definition  between  engineering  operations,  customers,  and 
suppliers  and  through  a  translator  provides  an  exchange  medium 
to  another  company.  The  EXPRESS  language  used  in  PDES  is  an 
outgrowth  of  the  PDDI  project. 

Product  Data  Exchange  Specification  (PDES)  -  McAir  has 
been  actively  involved  in  the  development  of  PDES  since  its 
inception.  The  technology  in  PDES  was  partially  derived  from 


McAir's  Product  Definition  Data  Interface  (PDDI)  project. 
McAir  has  contributed  to  the  PDES  standard  development  effort 
through  its  technical  expertise  in  digital  data  exchange  and 
chairmanship  of  PDES  standards  development  subcommittees  such 
as  drafting,  logical  layer,  manufacturing,  physical  layer,  and 
technical  publications. 

Jerry  Weiss  of  McAir  is  the  convener  of  the  international 
PDES/STEP  committee.  McAir  has  accepted  a  leadership 
position  in  PDES,  Inc.  and  is  one  of  its  charter  members. 

Geometric  Modeling  Applications  Interface  (GMAP)  -  The 
objective  of  this  R&D  project  is  to  identify  and  organize  the 
geometric  and  nonshape  data  needed  for  the  engineering, 
manufacturing,  and  logistics  support  of  complex  structured 
components;  and  demonstrate  a  digital  technology  for  the 
communication  and  manipulation  of  such  data  for  turbine  blades 
and  disks.  The  McAir's  contribution,  as  a  subcontractor,  of 
GMAP  include  the  following:  the  definition  and  modeling  of 
product  data  for  engine  blades  and  disks,  a  survey  of 
geometric  modeling,  and  the  demonstration  of  the  integration 
of  a  prime  contractor's  development  efforts  and  products  with 
both  the  vendor's  and  the  Air  Force's  Logistics  Center  depot 
systems. 

Data  Product  Model  (DPM)  -  The  PDDI  developed  technology 
is  being  applied  to  the  development  of  a  digital  product  model 
for  use  on  the  Air  Force  Advanced  Tactical  Fighter  (ATF)  with 
the  goal  of  establishing  a  methodology  to  replace  ATF  drawings 
with  electronic  digital  data.  The  Statement  of  Work  for  the 
ATF/ DPM  calls  for  constructing  digital  product  models, 
demonstrating  the  transportability  of  the  models, 
demonstrating  the  applicability  of  digital  product  data, 
evaluating  cost/benefits  and  potential  problems,  and 
recommending  an  evolutionary  path  for  Air  Force  data 
acquisition  policies.  This  ATF/ DPM  project  is  scheduled  for 
completion  in  1991  at  which  time  an  ATF/ PDES  project  will  be 
initiated. 
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3.2  OVERVIEW  OF  NEWPORT  NEWS  SHIPBUILDING  APPROACH  TO 
DIGITAL  DATA  EXCHANGE 

3.2.1  CORPORATE  OBJECTIVE 

Newport  News  Shipbuilding  (NNS)  is  one  of  the  navy's 
leading  shipbuilders.  As  a  Navy  prime  contractor  for 
nuclear-powered  aircraft  carriers  and  submarines,  two  of  the 
most  complex  and  expensive  weapons  systems  in  existence,  NNS 
developed  extensive  in-house  CAD/CAM  and  integrated  logistic 
support  capabilities.  The  designing  of  the  advanced 
submarine,  SSN-21,  is  being  jointly  developed  by  both  NNS  and 
General  Dynamics/Electric  Boat  Division  (GD/EB) ,  digital  data 
sharing  between  these  two  corporations  and  their 
subcontractors  has  become  a  necessity. 

In  order  to  become  more  competitive  and  achieve  business 
performance  improvement,  NNS  has  committed  themselves  to  the 
development  and  implementation  of  a  product  model,  the 
automation  of  integrated  logistic  support,  and  the  development 
of  an  integrated  publishing  system  for  use  on  the  SSN-21. 


3.2.2  STRATEGY  TO  ACCOMPLISH  THE  OBJECTIVE 
The  strategy  to  accomplish  the  objective  is: 

-  to  capture  digital  data  early  in  the  design  phase 
and  to  develop  a  3-D  digital  product  model  for 
ship's  engineering  data, 

-  to  produce  LSA  concurrently  with  engineering 
design, 

-  to  promote  the  modernization  of  the  infrastructure 
that  will  create,  receive,  review,  store,  and  use 
those  digital  data  products, 

-  to  relieve  the  in-house  data  exchange  problems  by 
adapting  primarily  IBM  computing  equipment, 

-  to  develop  digital  data  exchange  capabilities  with 
outside  vendors, 

-  to  proceed  towards  integrating  the  work  processes 
within  their  company,  and 

-  to  participate  in  digital  data  exchange  standards 
development  efforts  in  IGES/PDES  and  in  the 
Navy/Industry  Digital  Data  Exchange  Standards 
Committee  (NIDDESC) . 


3.2.3  APPROACH 


SSN-21  is  the  only  new  ship  design  by  NNS  since  the  early 
1970's.  Nevertheless,  NNS ' s  approach  to  implementing  CALS 
technology  is  not  intended  to  fundamentally  change  the  way  a 
ship  is  designed.  It  is  intended  to  capture  the  data  that  is 
developed  as  a  natural  part  of  the  ship  design  and 
shipbuilding  process  and  to  establish  key  relationships  among 
the  data  that  ensure  functional  integration  of  information 
systems  and  processes.  This  is  intended  to  reduce  and 
eliminate  the  need  for  multiple  iterations  of  data  in 
redundant  files,  reduce  the  volume  and  cost  of  deliverables, 
and  improve  the  quality,  accessibility,  and  responsiveness  of 
the  data  that  creates  the  deliverables. 

The  ship  product  data  model  is  to  create  a  single 
geometric  description  of  the  ship  "as  designed"  and  "as 
built".  The  main  advantage  of  the  three  dimensional  modeling 
technique  is  the  ability  to  create  an  item  only  once  and 
retain  only  sufficient  attributes  to  physically  describe  the 
item  within  the  model  context.  These  items  are  then  related 
to  the  specifications,  standards,  documents,  and  other 
technical  data  that  define  the  item.  Establishment  of  these 
relationships  support  the  integration  of  the  engineering, 
configuration,  and  logistic  data. 

*  Product  Data  Model  and  VIVID  Database: 

The  development  and  maintaining  of  the  geometric 
description  of  the  ship  is  referred  to  by  NNS  as  the  "Product 
Data  Model"  which  is  produced  by  174  work  stations  (IBM/CADAM) 
for  drafting,  structural  design,  and  performing  stress 
analysis.  This  Product  Data  Model  is  stored  in  the  CADAM  2D 
and  CADAM  3D  databases.  Also  there  are  41  solid  modeling  work 
stations  (Lexidata/Graphicon)  used  for  outfitting  modeling  in 
VIVID.  VIVIL  incorporates  an  interactive  solid  display  for 
component  modeling  and  arranging  of  distributive  systems  in 
the  ship.  In  addition,  there  are  two  ComputerVision  (CV) 
systems  at  NNS  supporting  8  to  10  work  stations.  These  CV 
systems  are  used  primarily  for  NC  shape  cutting  of  sheet  metal 
and  manufacturing  of  machinery  items.  Interfaces  between 
CADAM  2D,  CADAM  3D  and  VIVID  have  been  developed  and  the  IBM 
Internal  Format  (IIF)  is  used  for  internal  exchange  between 
systems  within  NNS. 

An  Electronic  Design  Release  Center  has  been 
established  at  NNS  as  the  place  for  the  storage  of  the 
approved  for  released  version  of  the  digital  data  drawings  and 
for  the  controlling  of  the  digital  drawing  release  process. 
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*  Integrated  Logistic  Support: 

NNS  is  building  an  interim  and  partial  system  of 
SEAWOLF  Automated  Integrated  Logistic  Support  System  (SAILSS) 
to  meet  the  ILS  schedule  for  SSN-21.  The  functional 
specifications  for  SAILSS  is  currently  being  developed  and  is 
being  designed  to  integrate  design  data  with  logistic  data  as 
well  as  to  ensure  data  continuity  between  the  acquisition  and 
operational  phases  of  the  ship-class.  The  Expanded  Ship  Work 
Breakdown  Structure/Function  Group  Code  (ESWBS/FGC)  which 
permits  integration  and  interaction  with  respective  technical 
and  logistic  information  will  be  the  common  data  link  between 
SAILSS  and  other  logistic  subsystems;  it  will  maintain  this 
identity  across  each  hull  of  the  class.  SAILSS  will  produce 
SEAWOLF  logistics  products  such  as  maintenance  plans,  training 
curricular  and  repair  standards  over  the  class  life  cycle. 
SAILSS  will  be  a  composite  of  individual  subsystems,  linked 
by  on-line  software  programs,  common  data  elements  and  a 
telecommunications  network  and  will  be  centralized  at  the  lead 
design  yard  and  will  be  available  to  remote  user  work  stations 
through  telecommunication  lines. 

*  Digital  Data  Exchange: 

Extensive  digital  data  exchange  capability  has  been 
established  between  NNS  and  GD/EB.  The  following  table  lists 
the  current  situation: 


TYPE  OF 


DATA 

INTERFACE 

STATUS 

GUIDELINE 

FREOUENCY 

2-D  Drawing 

IGES  3.0 
Magnetic 

tape 

Production 

PMS  350 

DDEP-001 

DPMC-007 

Upon 

request 

3-D  Structure 
Magnetic  tape 

IGES  3.0 

Production 

PMS  350 

DPMS-004 

DPMC-007 

100% 

3-D  Piping 
design 

IGES  4.0 
Magnetic 

tape 

Final  Test 
7/89 

PMS  350 

DDEP-005 

DPMC-007 

100% 

Non-proce- 
ssable  text 

Wang  OSI 
disk 

on 

Production 

PMS  350 
DDEP-006 

Upon 

request 

Processable 

text 

EBCDIC 

Magnetic 

tape 

Production 

PMS  350 
DED-002 
DED-003 

Regularly/ 

Upon 

request 
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3.3  OVERVIEW  OF  NORTHROP' S  APPROACH  TO  DIGITAL  DATA 

EXCHANGE 

3.3.1  CORPORATE  OBJECTIVE 

Northrop  has  made  a  corporate  commitment  to  advancing 
and  improving  product  data  exchange  practice  by  means  of 
data  sharing  and  standards.  Northrop' s  goal  is  to  improve 
weapon  systems  affordability  by  managing  information  as  a 
critical  resource  to  design,  manufacture,  and  support  the 
product  using  advanced  information  technology. 


3.3.2  STRATEGY  TO  ACCOMPLISH  THE  OBJECTIVE 

The  Northrop  Aircraft  Division  has  developed  a 
strategic  plan  known  as  the  Northrop  Aircraft  Division 
Strategic  Architecture  Plan  (NADSARP)  for  future 
capabilities.  Since  the  completion  of  the  NADSARP  document 
in  1986,  only  projects  which  fit  the  NADSARP  architecture 
are  approved.  The  key  element  in  Northrop 's  transition  from 
product  development  to  production  is  the  Product  Definition 
Development  Center  (PDDC)  concept  which  is  a  commitment  to 
change  in  ways  to  design,  plan,  and  support  the  products  and 
is  a  strategy  that  defines  the  weapon  system  from  a  common 
data  base,  providing  the  product  definition,  delivery  and 
support  with  simultaneous  access  to  product  information. 

3.3.3  APPROACH 

The  Northrop  approach  to  achieving  this  objective  is: 

-  to  participate  in  digital  data  exchange  standards 
development  efforts, 

-  to  develop  enabling  technology, 

-  to  implement  the  Product  Definition  Development 
Center  concept,  and 

-  to  proceed  towards  integrating  the  work  processes 
within  their  company. 


3.3.4  MAJOR  ACTIVITIES  IN  SUPPORT  OF  APPROACH 

Product  Definition  Development  Center  (PDDC)  -  PDDC  is 
not  a  place  but  a  concept  where  people,  processes  and 
automated  tools  work  together  as  a  product  definition  team. 
The  functioning  of  PDDC  results  in  the  concurrent,  active 
involvement  of  technical  personnel  in  all  product  definition 
disciplines  (design  and  analyses,  manufacturing,  material, 
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quality  assurance  and  logistics  support  personnel) ,  to 
create  a  digital  product  definition.  The  initial 
implementation  of  the  PDDC  concept  is  operating  in  the 
Advanced  Tactical  Fighter  (ATF)  Prototype  Program.  The  Full 
Scale  Development  (FSD)  Program  of  ATF  is  much  more  complex 
than  the  ATF  Prototype  Program  environment.  The  following 
two  projects  for  PDDC  concept  implementation  which  relate  to 
digital  data  sharing  are  being  developed  for  the  ATF/FSD 
Program: 


1.  PDDC  Shared  Data  Base  -  The  goal  is  to  develop  and 
implement  a  single  shareable  product  definition  data  base  in 
which  all  users  and  applications  add  value  or  query  the 
information  that  composes  the  product  definition  which 
includes  engineering,  manufacturing,  and  ILS  data.  The 
completion  of  the  this  Shared  Data  base  is  expected  by  the 
end  of  1990. 

2.  Integrated  Configuration  and  Management  System 
(ICMS)  -  ICMS  is  the  aggregate  of  and  the  linkage  of  the 
manual  and  automated  systems  (business,  text,  graphics  and 
geometry)  that  are  used  during  the  requirements,  definition, 
implementation,  verification,  and  compliance  phases  to 
ensure  traceability  from  the  specification  requirements  to 
the  product  configuration  throughout  the  product  life  cycle. 
ICMS  interfaces  to  the  various  organizations,  subcontractors 
and  suppliers  that  make  a  functional  contribution  to  product 
definition. 

Product  Data  Exchange  Specification  (PDES)  -  Northrop 
has  been  actively  involved  in  the  development  of  PDES. 
Northrop  has  contributed  to  the  PDES  standard  development 
effort  through  its  technical  expertise  in  digital  data 
exchange  and  leadership  to  the  standard  development  effort. 
Northrop  is  a  member  of  the  PDES,  Inc. 

Data  Product  Model  (DPM)  -  The  DPM  is  an  Air  Force 
contracted  demonstration  and  feasibility  study,  aimed  at 
replacing  engineering  drawings  with  electronic  digital  data 
and  providing  proof-of -concept  for  PDES.  The  use  of  DPM's 
during  the  Advanced  Tactical  Fighter  (ATF)  full  scale 
development  is  expected  to  contribute  significantly  to  the 
CALS  initiative  by  providing  an  integrated  database  for 
product  definition.  The  DPM  effort  comprises  three  major 
initiatives: 

-  data  modeling  to  define  the  complete  geometric 
definition, 
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-  demonstrations  of  PDES  Level  2  (active  file 
exchange)  to  be  conducted  at  McAir,  and  Level  3 
(shared  database  access)  to  be  conducted  at 
Northrop,  and 

-  evaluating  cost/benefits  and  potential 
problems,  and  recommending  an  evolutionary  path 
for  Air  Force  data  acquisition  policies. 

This  ATF/DPM  project  is  scheduled  for  completion  in 
1991  at  which  time  an  ATF/PDES  project  will  be  initiated. 
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3.4  OVERVIEW  OF  WESTINGHOUSE ' S  APPROACH  TO  DIGITAL  DATA 

EXCHANGE 

3.4.1  CORPORATE  OBJECTIVE 

Westinghouse  Engineering  Electronic  Systems  Group  (ESG) 
employs  more  than  30,000  workers  and  has  engineering, 
manufacturing,  and  maintenance  offices  and  factories 
throughout  the  United  States  and  many  foreign  countries. 

ESG  has  a  diversified  business  with  the  Government,  and 
produces  a  variety  of  consumer  products.  In  order  to 
achieve  business  performance  improvement,  ESG  has  committed 
themselves  to  the  development  and  implementation  of  an 
integrated  information  system  to  manage,  control,  and 
integrate  engineering  data,  processes  and  processing 
hardware. 


3.4.2  STRATEGY  TO  ACCOMPLISH  THE  OBJECTIVE 

The  strategy  to  accomplish  the  objective  is  the 
development  of  the  Westinghouse  Integrated  Systems  for 
Engineering  (WISE)  project.  WISE  is  an  information  system 
which  is  currently  being  developed  to  integrate 
Westinghouse ' s  Electronic  Systems  Group's  heterogeneous 
CAD/CAE/ CAM  environment,  and  to  support  a  concurrent 
engineering  initiative.  WISE  will  capture  information  early 
in  the  life  cycle  and  will  facilitate: 

-  downstream  use  of  data, 

-  consistent  life  cycle  configuration  management, 

-  distribution  of  data  to  support  local 
applications,  and 

-  inter-organizational  use  and  management  of 
data. 

Since  1987,  ESG  has  been  developing  the  WISE  prototype 
system.  If  the  development  is  successful,  WISE  will  be 
expanded  to  support  Westinghouse  nation-wide  and  it  may 
become  a  commercial  product.  A  demonstration  of  the  WISE 
prototype  is  scheduled  in  early  1990. 


3.4.3  APPROACH 

The  backbone  of  WISE  is  the  implementation  of  a 
distributed  processing  and  integrated  network  architecture 
which  will: 


-  provide  a  fault-tolerant  distributed  processing 
environment  nation-wide  linking  WISE 
local-nodes, 


80 


provide  local  WISE  network-node  services 
which  will  achieve  integration  of  heterogeneous 
CAD/ CAE/CAM  environments  (a  WISE  local  node  may 
be  installed  anywhere  in  the  world) , 

establish  an  interactive  product  life-cycle 
design  support  environment  for  group  technology 
and  concurrent  engineering,  and 

establish  configuration  controlled  document 
release  and  electronic  vault  mechanisms  for 
both  magnetic  and  WORM  storage. 
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4.0  IDENTIFICATION  OF  NAVY  ISSUES  ACTIVITIES  TO  BE  INCLUDED  IN 

PART  II 

The  next  step,  part  II,  in  approaching  a  Navy  digital  data 
exchange  strategy  will  be  to  review  the  data  exchange 
activities/approaches  associated  with  the  following  on-going  Navy 
weapons  systems:  SSN-21,  DDG-51,  A-12,  V-22,  and  the  MCM  Product 
Model.  These  weapons  systems  development  efforts  are  expected  to 
provide  input  to  the  strategy  by  investigating  the  approaches 
taken  by  these  programs  in  integrating  their  data  bases  for  CAD, 
CAM,  engineering  and  logistics  analyses  and  how  they  generate  and 
transfer  drawings,  technical  manuals,  training  materials,  supply 
data,  and  other  products  in  digital  form. 

In  addition  to  investigating  these  Navy  weapons  systems  data 
exchange  activities,  other  services  approaches  to  digital  data 
exchange  will  be  investigated. 

The  information  gathered  in  this  step  will  provide  the 
necessary  input  to  develop  a  coherent  Navy-wide  strategy  for 
digital  data  exchange  of  logistics  technical  information. 
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